diff --git a/docs/docs/20-usage/40-secrets.md b/docs/docs/20-usage/40-secrets.md index 2c7065815c..67f0916772 100644 --- a/docs/docs/20-usage/40-secrets.md +++ b/docs/docs/20-usage/40-secrets.md @@ -17,27 +17,72 @@ In this example, the secret named `secret_token` would be passed to the setting ```diff steps: - - name: docker - image: my-plugin -+ environment: -+ TOKEN_ENV: -+ from_secret: secret_token + - name: 'plugin step' + image: registry/repo/image:tag + settings: + token: ++ from_secret: secret_token + + - name: 'some commands using secrets' + image: bash + commands: + - env | grep TOKEN ++ environment: ++ TOKEN_ENV: + from_secret: secret_token ``` +:::info Important +Avoid using the deprecated `secrets` or `environment` fields in plugin steps. +These options can potentially impact plugin execution and integrity. +Instead, provide secrets via the `settings` field, preferably using the `from_secret` syntax (see below). + +This rule is also enforced by the pipeline linter to promote safe and predictable plugin behavior. +::: + +In the example below, the secret `SURGE_TOKEN` would be passed to the setting named `surge_token`, which will be available in the plugin as an environment variable named `PLUGIN_SURGE_TOKEN` (See [plugins](./51-plugins/20-creating-plugins.md#settings) for details). + +```yaml +steps: + - name: deploy-preview: + image: woodpeckerci/plugin-surge-preview + settings: + path: 'docs/build/' + surge_token: + from_secret: SURGE_TOKEN +``` + +As settings can have complex structures, `from_secret` is supported at any level: + +```yaml +steps: + - name: deploy-test: + image: plugin-example + settings: + path: 'artifacts' + simple_token: + from_secret: A_TOKEN + advanced_setting: + items: + - "value1" + - some: + from_secret: secret_value + - "value3" +``` + +This method ensures flexible and secure use of secrets within plugin settings, while preserving the integrity and security of the plugin execution environment. + ### Note about parameter pre-processing Please note parameter expressions are subject to pre-processing. When using secrets in parameter expressions they should be escaped. ```diff steps: - - name: docker - image: docker + - name: "step name" + image: registry/repo/image:tag commands: -- - echo ${TOKEN_ENV} -+ - echo $${TOKEN_ENV} +- - echo ${TOKEN} ++ - echo $${TOKEN} environment: TOKEN_ENV: from_secret: secret_token diff --git a/docs/versioned_docs/version-2.7/20-usage/40-secrets.md b/docs/versioned_docs/version-2.7/20-usage/40-secrets.md index 1b55d9ce15..e6a950295e 100644 --- a/docs/versioned_docs/version-2.7/20-usage/40-secrets.md +++ b/docs/versioned_docs/version-2.7/20-usage/40-secrets.md @@ -18,32 +18,66 @@ once their usage is declared in the `secrets` section: ```diff steps: - - name: docker - image: docker + - name: "step name" + image: registry/repo/image:tag commands: -+ - echo $docker_username -+ - echo $DOCKER_PASSWORD -+ secrets: [ docker_username, DOCKER_PASSWORD ] ++ - echo $some_username ++ - echo $SOME_PASSWORD ++ secrets: [ some_username, SOME_PASSWORD ] ``` -The case of the environment variables is not changed, but secret matching is done case-insensitively. In the example above, `DOCKER_PASSWORD` would also match if the secret is called `docker_password`. +The environment variables retain their original case, but secret matching is performed in a case-insensitive manner. +In this example, `DOCKER_PASSWORD` would still match even if the secret is named `docker_password`. -### Use secrets in settings and environment +### Use secrets in normal steps via environment -You can set an setting or environment value from secrets using the `from_secret` syntax. - -In this example, the secret named `secret_token` would be passed to the setting named `token`,which will be available in the plugin as environment variable named `PLUGIN_TOKEN` (See [plugins](./51-plugins/20-creating-plugins.md#settings) for details), and to the environment variable `TOKEN_ENV`. +You can set an environment value from secrets using the `from_secret` syntax. +So the secret key and environment variable name can differ. ```diff steps: - - name: docker - image: my-plugin + - name: test + image: bash + commands: + - env | grep OWN +- secrets: [ some_username, SOME_PASSWORD ] + environment: -+ TOKEN_ENV: -+ from_secret: secret_token -+ settings: -+ token: -+ from_secret: secret_token ++ SOME_OWN_DEFINED_VAR: ++ from_secret: some_username +``` + +### Use secrets in plugins via settings + +The `from_secret` syntax also work for settings in any hierarchy. + +In this example, the secret named `secret_token` would be passed to the setting named `SURGE_TOKEN`,which will be available in the plugin as environment variable named `PLUGIN_SURGE_TOKEN` (See [plugins](./51-plugins/20-creating-plugins.md#settings) for details). + +```diff + steps: + - name: deploy-preview: + image: woodpeckerci/plugin-surge-preview + settings: + path: 'docs/build/' ++ surge_token: ++ from_secret: SURGE_TOKEN +``` + +As settings can have complex structure, the `from_secret` is supported in all of it: + +```yaml +steps: + - name: deploy-test: + image: plugin-example + settings: + path: 'artifacts' + simple_token: + from_secret: A_TOKEN + advanced: + items: + - "value1" + - some: + from_secret: secret_value + - "value3" ``` ### Note about parameter pre-processing @@ -52,14 +86,14 @@ Please note parameter expressions are subject to pre-processing. When using secr ```diff steps: - - name: docker - image: docker + - name: "echo password" + image: bash commands: -- - echo ${docker_username} -- - echo ${DOCKER_PASSWORD} -+ - echo $${docker_username} -+ - echo $${DOCKER_PASSWORD} - secrets: [ docker_username, DOCKER_PASSWORD ] +- - echo ${some_username} +- - echo ${SOME_PASSWORD} ++ - echo $${some_username} ++ - echo $${SOME_PASSWORD} + secrets: [ some_username, SOME_PASSWORD ] ``` ### Use in Pull Requests events @@ -70,9 +104,11 @@ Secrets are not exposed to pull requests by default. You can override this behav Please be careful when exposing secrets to pull requests. If your repository is open source and accepts pull requests your secrets are not safe. A bad actor can submit a malicious pull request that exposes your secrets. ::: -## Image filter +## Plugins filter + +To prevent abusing your secrets from malicious usage, you can limit a secret to a list of plugins. If enabled they are not available to any other plugin (steps without user-defined commands). If you or an attacker defines explicit commands, the secrets will not be available to the container to prevent leaking them. -To prevent abusing your secrets from malicious usage, you can limit a secret to a list of images. If enabled they are not available to any other plugin (steps without user-defined commands). If you or an attacker defines explicit commands, the secrets will not be available to the container to prevent leaking them. +![plugins filter](./secrets-plugins-filter.png) ## Adding Secrets diff --git a/docs/versioned_docs/version-2.7/20-usage/51-plugins/20-creating-plugins.md b/docs/versioned_docs/version-2.7/20-usage/51-plugins/20-creating-plugins.md index 8a0ea59207..9631a64086 100644 --- a/docs/versioned_docs/version-2.7/20-usage/51-plugins/20-creating-plugins.md +++ b/docs/versioned_docs/version-2.7/20-usage/51-plugins/20-creating-plugins.md @@ -42,7 +42,7 @@ Values like this are converted to JSON and then passed to your plugin. In the ex ### Secrets -Secrets should be passed as settings too. Therefore, users should use [`from_secret`](../40-secrets.md#use-secrets-in-settings-and-environment). +Secrets should be passed as settings too. Therefore, users should use [`from_secret`](../40-secrets.md#use-secrets-in-plugins-via-settings). ## Plugin library diff --git a/docs/versioned_docs/version-2.7/20-usage/secrets-plugins-filter.png b/docs/versioned_docs/version-2.7/20-usage/secrets-plugins-filter.png new file mode 100644 index 0000000000..460d852fb0 Binary files /dev/null and b/docs/versioned_docs/version-2.7/20-usage/secrets-plugins-filter.png differ