open-nomad/website/content/docs/concepts/workload-identity.mdx
Tim Gross 4881f2451a
docs: describe the default Workload Identity ACL policy (#17245)
Workload Identities have an implicit default policy. This policy can't currently
be described via HCL because it includes task interpolation for Variables and
access to the Services API (which doesn't exist as its own ACL
capbility). Describe this in our WI documentation.

Fixes: #16277
2023-05-19 11:38:05 -04:00

108 lines
3.1 KiB
Plaintext

---
layout: docs
page_title: Workload Identity
description: Learn about Nomad's workload identity feature
---
# Workload Identity
Every workload running in Nomad is given an identity. When an [allocation][] is
accepted by the [plan applier][], the leader generates a Workload Identity for
each task in the allocation. This workload identity is a [JSON Web Token
(JWT)][] that has been signed by the leader's keyring. The workload identity
includes the following identity claims:
```json
{
"nomad_namespace": "default",
"nomad_job_id": "example",
"nomad_allocation_id": "5c6328f7-48c5-4d03-bada-91ef2e904d0d",
"nomad_task": "web"
}
```
## Using Workload Identity
While Nomad always creates and uses workload identities internally, the JWT is
not exposed to tasks by default.
To expose Workload Identity to tasks, add an [`identity`][identity-block] block
to your jobspec:
```hcl
task "example" {
identity {
# Expose Workload Identity in NOMAD_TOKEN env var
env = true
# Expose Workload Identity in ${NOMAD_SECRETS_DIR}/nomad_token file
file = true
}
}
```
## Default Workload ACL Policy
By default, a Workload Identity has access to a implicit ACL policy. This policy
grants access to Nomad Variables associated with the job, group, and task, as
described in [Task Access to Variables][]. The implicit policy also allows
access to list or read any Nomad service registration as with the [List Services
API][] or [Read Service API][].
## Workload Associated ACL Policies
You can associate additional ACL policies with workload identities by passing
the `-job`, `-group`, and `-task` flags to `nomad acl policy apply`. When Nomad
resolves a workload identity claim, it will automatically include policies that
match. If no matching policies exist, the workload identity does not have any
additional capabilities.
For example, to allow a workload access to secrets from the namespace "shared",
you can create the following policy file:
```hcl
namespace "shared" {
variables {
path "*" {
capabilities = ["read"]
}
}
}
```
You can then apply this policy to a specific task:
```shell-session
nomad acl policy apply \
-namespace default -job example -group cache -task redis \
redis-policy ./policy.hcl
```
You can also apply this policy to all tasks in the group by omitting the `-task`
flag:
```shell-session
nomad acl policy apply \
-namespace default -job example -group cache \
redis-policy ./policy.hcl
```
And you can apply this policy to all groups in the job by omitting both the
`-group` and `-task` flag:
```shell-session
nomad acl policy apply \
-namespace default -job example \
redis-policy ./policy.hcl
```
[allocation]: /nomad/docs/concepts/architecture#allocation
[identity-block]: /nomad/docs/job-specification/identity
[plan applier]: /nomad/docs/concepts/scheduling/scheduling
[JSON Web Token (JWT)]: https://datatracker.ietf.org/doc/html/rfc7519
[Task Access to Variables]: /nomad/docs/concepts/variables#task-access-to-variables
[List Services API]: /nomad/api-docs/services#list-services
[Read Service API]: /nomad/api-docs/services#read-service