diff --git a/website/content/docs/commands/operator/root/keyring-install.mdx b/website/content/docs/commands/operator/root/keyring-install.mdx new file mode 100644 index 000000000..b8453c02d --- /dev/null +++ b/website/content/docs/commands/operator/root/keyring-install.mdx @@ -0,0 +1,32 @@ +--- +layout: docs +page_title: 'Commands: operator root keyring install' +description: | + Install an encryption key +--- + +# Command: operator root keyring install + +The `operator root keyring install` command installs a new encryption key used +for variables and workload identity signing. The key file must be a JSON file +previously written by Nomad to the keystore. The key file will be read from +stdin by specifying "-", otherwise a path to the file is expected. + +If ACLs are enabled, this command requires a management token. + +## Usage + +```plaintext +nomad operator root keyring install [options] +``` + +## General Options + +@include 'general_options.mdx' + +## Examples + +```shell-session +$ nomad operator root keyring install ./14ba0470-a5b4-41f4-a1e4-83b4c82d1324.nks.json +Installed encryption key 14ba0470-a5b4-41f4-a1e4-83b4c82d1324 +``` diff --git a/website/content/docs/commands/operator/secure-variables/keyring-list.mdx b/website/content/docs/commands/operator/root/keyring-list.mdx similarity index 59% rename from website/content/docs/commands/operator/secure-variables/keyring-list.mdx rename to website/content/docs/commands/operator/root/keyring-list.mdx index be2b63c19..e049b8b79 100644 --- a/website/content/docs/commands/operator/secure-variables/keyring-list.mdx +++ b/website/content/docs/commands/operator/root/keyring-list.mdx @@ -1,22 +1,21 @@ --- layout: docs -page_title: 'Commands: operator secure-variables keyring list' +page_title: 'Commands: operator root keyring list' description: | List encryption key metadata --- -# Command: operator secure-variables keyring list +# Command: operator root keyring list -The `operator secure-variables keyring list` command lists the -currently installed keys. This list returns key metadata and not -sensitive key material. +The `operator root keyring list` command lists the currently installed +keys. This list returns key metadata and not sensitive key material. If ACLs are enabled, this command requires a management token. ## Usage ```plaintext -nomad operator secure-variables keyring list [options] +nomad operator root keyring list [options] ``` ## General Options @@ -30,12 +29,12 @@ nomad operator secure-variables keyring list [options] ## Examples ```shell-session -$ nomad operator secure-variables keyring list +$ nomad operator root keyring list Key State Create Time 33374156 active 2022-07-11T19:11:07Z 8d87a371 inactive 2022-07-11T19:10:37Z -$ nomad operator secure-variables keyring list -verbose +$ nomad operator root keyring list -verbose Key State Create Time 33374156-9f81-b14c-83d4-a2f1f87dbf99 active 2022-07-11T19:11:07Z 8d87a371-3594-e1e4-8ae1-3980122b0f25 inactive 2022-07-11T19:10:37Z diff --git a/website/content/docs/commands/operator/root/keyring-remove.mdx b/website/content/docs/commands/operator/root/keyring-remove.mdx new file mode 100644 index 000000000..bcf701378 --- /dev/null +++ b/website/content/docs/commands/operator/root/keyring-remove.mdx @@ -0,0 +1,34 @@ +--- +layout: docs +page_title: 'Commands: operator root keyring remove' +description: | + Remove an unused encryption key +--- + +# Command: operator root keyring remove + +The `operator root keyring remove` command removes an encryption key from the +cluster. This operation may only be performed on keys that are not the active +key. + +If ACLs are enabled, this command requires a management token. + +## Usage + +```plaintext +nomad operator root keyring remove [options] +``` + +## General Options + +@include 'general_options.mdx' + +## Examples + +```shell-session +$ nomad operator root keyring remove 48596ce5-3ff5-8f77-2dcf-301682ada0ce +error: Unexpected response code: 500 (active root key cannot be deleted - call rotate first) + +$ nomad operator root keyring remove 33374156-9f81-b14c-83d4-a2f1f87dbf99 +Removed encryption key 33374156-9f81-b14c-83d4-a2f1f87dbf99 +``` diff --git a/website/content/docs/commands/operator/secure-variables/keyring-rotate.mdx b/website/content/docs/commands/operator/root/keyring-rotate.mdx similarity index 51% rename from website/content/docs/commands/operator/secure-variables/keyring-rotate.mdx rename to website/content/docs/commands/operator/root/keyring-rotate.mdx index 6e0f4bd33..2ba424ef2 100644 --- a/website/content/docs/commands/operator/secure-variables/keyring-rotate.mdx +++ b/website/content/docs/commands/operator/root/keyring-rotate.mdx @@ -1,21 +1,21 @@ --- layout: docs -page_title: 'Commands: operator secure-variables keyring rotate' +page_title: 'Commands: operator root keyring rotate' description: | Rotate encryption key --- -# Command: operator secure-variables keyring rotate +# Command: operator root keyring rotate -The `operator secure-variables keyring rotate` command generates a new -encryption key for all future variables. +The `operator root keyring rotate` command generates a new encryption key for +all future variables. If ACLs are enabled, this command requires a management token. ## Usage ```plaintext -nomad operator secure-variables keyring rotate [options] +nomad operator root keyring rotate [options] ``` ## General Options @@ -24,20 +24,20 @@ nomad operator secure-variables keyring rotate [options] ## Rotate Options -- `-full`: Decrypt all existing variables and re-encrypt with the new - key. This command will immediately return and the re-encryption - process will run asynchronously on the leader. +- `-full`: Decrypt all existing variables and re-encrypt with the new key. This + command will immediately return and the re-encryption process will run + asynchronously on the leader. - `-verbose`: Enable verbose output ## Examples ```shell-session -$ nomad operator secure-variables keyring rotate +$ nomad operator root keyring rotate Key State Create Time f19f6029 active 2022-07-11T19:14:36Z -$ nomad operator secure-variables keyring rotate -verbose +$ nomad operator root keyring rotate -verbose Key State Create Time 53186ac1-9002-c4b6-216d-bb19fd37a791 active 2022-07-11T19:14:47Z ``` diff --git a/website/content/docs/commands/operator/secure-variables/keyring-install.mdx b/website/content/docs/commands/operator/secure-variables/keyring-install.mdx deleted file mode 100644 index b2e11fabb..000000000 --- a/website/content/docs/commands/operator/secure-variables/keyring-install.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: docs -page_title: 'Commands: operator secure-variables keyring install' -description: | - Install an encryption key ---- - -# Command: operator secure-variables keyring install - -The `operator secure-variables keyring install` command installs a new -encryption key used for secure variables and workload identity -signing. The key file must be a JSON file previously written by Nomad -to the keystore. The key file will be read from stdin by specifying -"-", otherwise a path to the file is expected. - -If ACLs are enabled, this command requires a management token. - -## Usage - -```plaintext -nomad operator secure-variables keyring install [options] -``` - -## General Options - -@include 'general_options.mdx' - -## Examples - -```shell-session -$ nomad operator secure-variables keyring install ./14ba0470-a5b4-41f4-a1e4-83b4c82d1324.nks.json -Installed encryption key 14ba0470-a5b4-41f4-a1e4-83b4c82d1324 -``` diff --git a/website/content/docs/commands/operator/secure-variables/keyring-remove.mdx b/website/content/docs/commands/operator/secure-variables/keyring-remove.mdx deleted file mode 100644 index 1a3dc6f21..000000000 --- a/website/content/docs/commands/operator/secure-variables/keyring-remove.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -layout: docs -page_title: 'Commands: operator secure-variables keyring remove' -description: | - Remove an unused encryption key ---- - -# Command: operator secure-variables keyring remove - -The `operator secure-variables keyring remove` command removes an -encryption key from the cluster. This operation may only be performed -on keys that are not the active key. - -If ACLs are enabled, this command requires a management token. - -## Usage - -```plaintext -nomad operator secure-variables keyring remove [options] -``` - -## General Options - -@include 'general_options.mdx' - -## Examples - -```shell-session -$ nomad operator secure-variables keyring remove 48596ce5-3ff5-8f77-2dcf-301682ada0ce -error: Unexpected response code: 500 (active root key cannot be deleted - call rotate first) - -$ nomad operator secure-variables keyring remove 33374156-9f81-b14c-83d4-a2f1f87dbf99 -Removed encryption key 33374156-9f81-b14c-83d4-a2f1f87dbf99 -``` diff --git a/website/content/docs/concepts/secure-variables.mdx b/website/content/docs/concepts/secure-variables.mdx deleted file mode 100644 index 852917f39..000000000 --- a/website/content/docs/concepts/secure-variables.mdx +++ /dev/null @@ -1,163 +0,0 @@ ---- -layout: docs -page_title: Secure Variables -description: Learn about Nomad's secure variables feature ---- - -# Secure Variables - -Most Nomad workloads need access to config values or secrets. Nomad has a -`template` block to provide such configuration to tasks, but has left the role -of storing that configuration to external services such as [HashiCorp Consul] -and [HashiCorp Vault]. - -Nomad's Secure Variables feature provides the option to securely store -configuration at file-like paths directly in Nomad's state store. The contents -of these secrets are encrypted and replicated between servers via raft. Access -to secrets is controlled by ACL policies, and tasks have implicit ACL policies -that allow them to access their own secrets. You can create, read, update, or -delete secrets via the command line, the Nomad API, or in the Nomad web UI. - -Note that the Secure Variables feature is intended for small pieces of -configuration data needed by workloads. Because writing to the Nomad state store -uses resources needed by Nomad, it is not well-suited for large or fast-changing -data. For example, do not store batch job results as Secure Variables - these -should be stored in an external database. Secure Variables are also not intended -to be a full replacement for HashiCorp Vault. If you need powerful options like -dynamic secrets or transit encryption, continue using Vault. - -## ACL for Secure Variables - -Every Secure Variable belongs to a specific Nomad namespace. ACL policies can -restrict access to Secure Variables within a namespace on a per-path basis, -using a list of `path` blocks, located under `namespace.secure_variables`. See -the [ACL policy specification] docs for details about the syntax and structure -of an ACL policy. - -Path definitions may also include wildcard symbols, also called globs, allowing -a single path policy definition to apply to a set of paths within that -namespace. For example, the policy below allows full access to secure variables -at all paths in the "dev" namespace that are prefixed with "project/" (including -child paths) but only read access to paths prefixed with "system/". Note that -the glob can match an empty string and all other characters. This policy grants -read access to paths prefixed with "system/" but not a path named "system" -(without a trailing slash). - -```hcl -namespace "dev" { - policy = "write" - capabilities = ["alloc-node-exec"] - - secure_variables { - - # full access to secrets in all "project" paths - path "project/*" { - capabilities = ["write", "read", "destroy", "list"] - } - - # read/list access within a "system/" path belonging to administrators - path "system/*" { - capabilities = ["read"] - } - } -} -``` - -The available capabilities for Secure Variables are as follows: - -| Capability | Notes | -|------------|------------------------------------------------------------------------------------------------------------------------------| -| write | Create or update Secure Variables at this path. Includes the "list" capability but not the "read" or "destroy" capabilities. | -| read | Read the decrypted contents of Secure Variables at this path. Also includes the "list" capability | -| list | List the metadata but not contents of Secure Variables at this path. | -| destroy | Delete Secure Variables at this path. | - -## Task Access to Secure Variables - -In Nomad 1.4.0 tasks can only access Secure Variables with the [`template`] -block. The [workload identity] for each task grants it automatic read and list -access to Secure Variables found at Nomad-owned paths with the prefix -`nomad/jobs/`, followed by the job ID, task group name, and task name. This is -equivalent to the following policy: - -```hcl -namespace "$namespace" { - secure_variables { - - path "nomad/jobs" { - capabilities = ["read", "list"] - } - - path "nomad/jobs/$job_id" { - capabilities = ["read", "list"] - } - - path "nomad/jobs/$job_id/$task_group" { - capabilities = ["read", "list"] - } - - path "nomad/jobs/$job_id/$task_group/$task_name" { - capabilities = ["read", "list"] - } - } -} -``` - -For example, a task named "redis", in a group named "cache", in a job named -"example", will automatically have access to Secure Variables as if it had the -following policy: - -```hcl -namespace "default" { - secure_variables { - - path "nomad/jobs" { - capabilities = ["read", "list"] - } - - path "nomad/jobs/example" { - capabilities = ["read", "list"] - } - - path "nomad/jobs/example/cache" { - capabilities = ["read", "list"] - } - - path "nomad/jobs/example/cache/redis" { - capabilities = ["read", "list"] - } - } -} -``` - -You can provide access to additional secrets by creating policies associated -with the task's [workload identity]. For example, to give the task above access -to all secrets in the "shared" namespace, you can create the following policy -file: - -```hcl -namespace "shared" { - secure_variables { - path "*" { - capabilities = ["read"] - } - } -} -``` - -Then create the policy and associate it with the specific task: - -```shell-session -nomad acl policy apply \ - -namespace default -job example -group cache -task redis \ - redis-policy ./policy.hcl -``` - -See [Workload Associated ACL Policies] for more details. - -[HashiCorp Consul]: https://consul.io -[HashiCorp Vault]: https://vaultproject.io -[ACL policy specification]: /docs/other-specifications/acl-policy -[`template`]: /docs/job-specification/template -[workload identity]: /docs/concepts/workload-identity -[Workload Associated ACL Policies]: /docs/concepts/workload-identity#workload-associated-acl-policies diff --git a/website/content/docs/concepts/variables.mdx b/website/content/docs/concepts/variables.mdx new file mode 100644 index 000000000..341a7e3c1 --- /dev/null +++ b/website/content/docs/concepts/variables.mdx @@ -0,0 +1,162 @@ +--- +layout: docs +page_title: Variables +description: Learn about Nomad's variables feature +--- + +# Variables + +Most Nomad workloads need access to config values or secrets. Nomad has a +`template` block to provide such configuration to tasks, but has left the role +of storing that configuration to external services such as [HashiCorp Consul] +and [HashiCorp Vault]. + +Nomad's Variables feature provides the option to securely store configuration at +file-like paths directly in Nomad's state store. The contents of these secrets +are encrypted and replicated between servers via raft. Access to secrets is +controlled by ACL policies, and tasks have implicit ACL policies that allow them +to access their own secrets. You can create, read, update, or delete secrets via +the command line, the Nomad API, or in the Nomad web UI. + +Note that the Variables feature is intended for small pieces of configuration +data needed by workloads. Because writing to the Nomad state store uses +resources needed by Nomad, it is not well-suited for large or fast-changing +data. For example, do not store batch job results as Variables - these should be +stored in an external database. Variables are also not intended to be a full +replacement for HashiCorp Vault. If you need powerful options like dynamic +secrets or transit encryption, continue using Vault. + +## ACL for Variables + +Every Variable belongs to a specific Nomad namespace. ACL policies can restrict +access to Variables within a namespace on a per-path basis, using a list of +`path` blocks, located under `namespace.variables`. See the [ACL policy +specification] docs for details about the syntax and structure of an ACL policy. + +Path definitions may also include wildcard symbols, also called globs, allowing +a single path policy definition to apply to a set of paths within that +namespace. For example, the policy below allows full access to variables at all +paths in the "dev" namespace that are prefixed with "project/" (including child +paths) but only read access to paths prefixed with "system/". Note that the glob +can match an empty string and all other characters. This policy grants read +access to paths prefixed with "system/" but not a path named "system" (without a +trailing slash). + +```hcl +namespace "dev" { + policy = "write" + capabilities = ["alloc-node-exec"] + + variables { + + # full access to secrets in all "project" paths + path "project/*" { + capabilities = ["write", "read", "destroy", "list"] + } + + # read/list access within a "system/" path belonging to administrators + path "system/*" { + capabilities = ["read"] + } + } +} +``` + +The available capabilities for Variables are as follows: + +| Capability | Notes | +|------------|-----------------------------------------------------------------------------------------------------------------------| +| write | Create or update Variables at this path. Includes the "list" capability but not the "read" or "destroy" capabilities. | +| read | Read the decrypted contents of Variables at this path. Also includes the "list" capability | +| list | List the metadata but not contents of Variables at this path. | +| destroy | Delete Variables at this path. | + +## Task Access to Variables + +In Nomad 1.4.0 tasks can only access Variables with the [`template`] block. The +[workload identity] for each task grants it automatic read and list access to +Variables found at Nomad-owned paths with the prefix `nomad/jobs/`, followed by +the job ID, task group name, and task name. This is equivalent to the following +policy: + +```hcl +namespace "$namespace" { + variables { + + path "nomad/jobs" { + capabilities = ["read", "list"] + } + + path "nomad/jobs/$job_id" { + capabilities = ["read", "list"] + } + + path "nomad/jobs/$job_id/$task_group" { + capabilities = ["read", "list"] + } + + path "nomad/jobs/$job_id/$task_group/$task_name" { + capabilities = ["read", "list"] + } + } +} +``` + +For example, a task named "redis", in a group named "cache", in a job named +"example", will automatically have access to Variables as if it had the +following policy: + +```hcl +namespace "default" { + variables { + + path "nomad/jobs" { + capabilities = ["read", "list"] + } + + path "nomad/jobs/example" { + capabilities = ["read", "list"] + } + + path "nomad/jobs/example/cache" { + capabilities = ["read", "list"] + } + + path "nomad/jobs/example/cache/redis" { + capabilities = ["read", "list"] + } + } +} +``` + +You can provide access to additional secrets by creating policies associated +with the task's [workload identity]. For example, to give the task above access +to all secrets in the "shared" namespace, you can create the following policy +file: + +```hcl +namespace "shared" { + variables { + path "*" { + capabilities = ["read"] + } + } +} +``` + +Then create the policy and associate it with the specific task: + +```shell-session +nomad acl policy apply \ + -namespace default -job example -group cache -task redis \ + redis-policy ./policy.hcl +``` + +See [Workload Associated ACL Policies] for more details. + +[HashiCorp Consul]: https://consul.io +[HashiCorp Vault]: https://vaultproject.io +[ACL policy specification]: /docs/other-specifications/acl-policy +[`template`]: /docs/job-specification/template +[workload identity]: /docs/concepts/workload-identity +[Workload Associated ACL Policies]: /docs/concepts/workload-identity#workload-associated-acl-policies diff --git a/website/content/docs/concepts/workload-identity.mdx b/website/content/docs/concepts/workload-identity.mdx index afb59382d..15bdbd7eb 100644 --- a/website/content/docs/concepts/workload-identity.mdx +++ b/website/content/docs/concepts/workload-identity.mdx @@ -33,7 +33,7 @@ you can create the following policy file: ```hcl namespace "shared" { - secure_variables { + variables { path "*" { capabilities = ["read"] } @@ -70,9 +70,9 @@ nomad acl policy apply \ ## Using Workload Identity In Nomad 1.4.0 the workload identity is used only for `template` -access to [Secure Variables][] and not exposed outside of Nomad. +access to [Variables][] and not exposed outside of Nomad. [allocation]: /docs/concepts/architecture#allocation [plan applier]: /docs/concepts/scheduling/scheduling -[Secure Variables]: /docs/concepts/secure-variables +[Variables]: /docs/concepts/variables [JSON Web Token (JWT)]: https://datatracker.ietf.org/doc/html/rfc7519 diff --git a/website/content/docs/operations/key-management.mdx b/website/content/docs/operations/key-management.mdx index 43e86c481..04d138bc8 100644 --- a/website/content/docs/operations/key-management.mdx +++ b/website/content/docs/operations/key-management.mdx @@ -6,11 +6,11 @@ description: Learn about the key management in Nomad. # Key Management -Nomad servers maintain an encryption keyring used to encrypt [Secure -Variables][] and sign task [workload identities][]. The servers store key -metadata in raft, but the encryption key material is stored in a separate file -in the `keystore` subdirectory of the Nomad [data directory][]. These files have -the extension `.nks.json`. +Nomad servers maintain an encryption keyring used to encrypt [Variables][] and +sign task [workload identities][]. The servers store key metadata in raft, but +the encryption key material is stored in a separate file in the `keystore` +subdirectory of the Nomad [data directory][]. These files have the extension +`.nks.json`. Under normal operations the keyring is entirely managed by Nomad, but this section provides administrators additional context around key replication and @@ -26,11 +26,10 @@ previously encrypted variables and verifying workload identities for existing allocations. If you believe key material has been compromised, you can execute [`nomad -operator keyring secure-variables rotate -full`][]. A new "active" key will be -created and "inactive" keys will be marked "rekeying". Nomad will asynchronously -decrypt and re-encrypt all secure variables with the new key. As each key's -variables are encrypted with the new key, the old key will marked as -"deprecated". +operator root keyring rotate -full`][]. A new "active" key will be created and +"inactive" keys will be marked "rekeying". Nomad will asynchronously decrypt and +re-encrypt all variables with the new key. As each key's variables are encrypted +with the new key, the old key will marked as "deprecated". ## Key Replication @@ -44,17 +43,16 @@ immediately before a leader election. ## Restoring the Keyring from Backup Key material is never stored in raft. This prevents an attacker with a backup of -the state store from getting access to encrypted secure variables. It also -allows the HashiCorp engineering and support organization to safely handle -cluster snapshots you might provide without exposing any of your keys or secure -variables. +the state store from getting access to encrypted variables. It also allows the +HashiCorp engineering and support organization to safely handle cluster +snapshots you might provide without exposing any of your keys or variables. However, this means that to restore a cluster from snapshot you need to also provide the keystore directory with the `.nks.json` key files on at least one server. Operators should include these files as part of your organization's backup and recovery strategy for the cluster. -[Secure Variables]: /docs/concepts/secure-variables +[Variables]: /docs/concepts/variables [workload identities]: /docs/concepts/workload-identity [data directory]: /docs/configuration#data_dir -[`nomad operator keyring secure-variables rotate -full`]: /docs/commands/operator/secure-variables/keyring-rotate.mdx +[`nomad operator root keyring rotate -full`]: /docs/commands/operator/root/keyring-rotate.mdx diff --git a/website/content/docs/other-specifications/acl-policy.mdx b/website/content/docs/other-specifications/acl-policy.mdx index 0e052be2a..735754c6e 100644 --- a/website/content/docs/other-specifications/acl-policy.mdx +++ b/website/content/docs/other-specifications/acl-policy.mdx @@ -29,8 +29,8 @@ namespace "foo" { policy = "write" # this is a policy field capabilities = ["alloc-exec"] # this is a capabilities list - # this block controls access to secure variables in this namespace - secure_variables { + # this block controls access to variables in this namespace + variables { path "project/*" { capabilities = ["read", "write"] } @@ -107,7 +107,7 @@ namespace "*" { ``` Each namespace rule can include a coarse-grained `policy` field, a fine-grained -`capabilities` field, a `secure_variables` block, or all three. +`capabilities` field, a `variables` block, or all three. The `policy` field for namespace rules can have one of the following values: - `read`: allow the resource to be read but not modified @@ -183,39 +183,39 @@ namespace "default" { } ``` -### Secure Variables +### Variables -The `secure_variables` block in the `namespace` rule controls access to [Secure -Variables][]. The secure variables block is optional, but you can specify only -one secure variables block per namespace rule. +The `variables` block in the `namespace` rule controls access to +[Variables][]. The variables block is optional, but you can specify only one +variables block per namespace rule. -A `secure_variables` block includes one or more `path` blocks. Each `path` block -is labeled with the path it applies to. You may use wildcard globs (`"*"`) in -the path label, to apply the block to multiple paths in the namespace. +A `variables` block includes one or more `path` blocks. Each `path` block is +labeled with the path it applies to. You may use wildcard globs (`"*"`) in the +path label, to apply the block to multiple paths in the namespace. -Each path has a list of `capabilities`. The available capabilities for Secure -Variables are as follows: +Each path has a list of `capabilities`. The available capabilities for Variables +are as follows: -| Capability | Notes | -|------------|------------------------------------------------------------------------------------------------------------------------------| -| write | Create or update Secure Variables at this path. Includes the "list" capability but not the "read" or "destroy" capabilities. | -| read | Read the decrypted contents of Secure Variables at this path. Also includes the "list" capability | -| list | List the metadata but not contents of Secure Variables at this path. | -| destroy | Delete Secure Variables at this path. | -| deny | No permissions at this path. Deny takes precedence over other capabilities. | +| Capability | Notes | +|------------|-----------------------------------------------------------------------------------------------------------------------| +| write | Create or update Variables at this path. Includes the "list" capability but not the "read" or "destroy" capabilities. | +| read | Read the decrypted contents of Variables at this path. Also includes the "list" capability | +| list | List the metadata but not contents of Variables at this path. | +| destroy | Delete Variables at this path. | +| deny | No permissions at this path. Deny takes precedence over other capabilities. | -For example, the policy below allows full access to secure variables at all -paths in the "dev" namespace that are prefixed with "project/", but only read -access to paths prefixed with "system/". Note that the glob can match an empty -string but all other characters are strictly matched. This policy grants read -access to paths prefixed with "system/" but not a path named "system" (without a -trailing slash). This policy does not grant any other coarse-grained policy or +For example, the policy below allows full access to variables at all paths in +the "dev" namespace that are prefixed with "project/", but only read access to +paths prefixed with "system/". Note that the glob can match an empty string but +all other characters are strictly matched. This policy grants read access to +paths prefixed with "system/" but not a path named "system" (without a trailing +slash). This policy does not grant any other coarse-grained policy or fine-grained capabilities. ```hcl namespace "dev" { - secure_variables { + variables { # full access to secrets in all "project" paths path "project/*" { @@ -402,4 +402,4 @@ The `policy` field for the plugin rule can have one of the following values: [api_quota]: /api-docs/quotas/ [host_volumes]: /docs/configuration/client#host_volume-stanza [api_plugins]: /api-docs/plugins/ -[Secure Variables]: /docs/concepts/secure-variables +[Variables]: /docs/concepts/variables diff --git a/website/data/docs-nav-data.json b/website/data/docs-nav-data.json index a721fbe78..cd1bd9d8a 100644 --- a/website/data/docs-nav-data.json +++ b/website/data/docs-nav-data.json @@ -148,8 +148,8 @@ "path": "concepts/workload-identity" }, { - "title": "Secure Variables", - "path": "concepts/secure-variables" + "title": "Variables", + "path": "concepts/variables" } ] }, @@ -632,6 +632,27 @@ } ] }, + { + "title": "root", + "routes": [ + { + "title": "keyring install", + "path": "commands/operator/root/keyring-install" + }, + { + "title": "keyring list", + "path": "commands/operator/root/keyring-list" + }, + { + "title": "keyring remove", + "path": "commands/operator/root/keyring-remove" + }, + { + "title": "keyring rotate", + "path": "commands/operator/root/keyring-rotate" + } + ] + }, { "title": "scheduler", "routes": [ @@ -645,27 +666,6 @@ } ] }, - { - "title": "secure-variables", - "routes": [ - { - "title": "keyring install", - "path": "commands/operator/secure-variables/keyring-install" - }, - { - "title": "keyring list", - "path": "commands/operator/secure-variables/keyring-list" - }, - { - "title": "keyring remove", - "path": "commands/operator/secure-variables/keyring-remove" - }, - { - "title": "keyring rotate", - "path": "commands/operator/secure-variables/keyring-rotate" - } - ] - }, { "title": "snapshot", "routes": [