Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: describe the default Workload Identity ACL policy #17245

Merged
merged 1 commit into from
May 19, 2023
Merged

docs: describe the default Workload Identity ACL policy #17245

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions website/content/docs/concepts/workload-identity.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,14 @@ task "example" {
}
```

## 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][].
Comment on lines +50 to +52
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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][].
described in [Task Access to Variables][]. The implicit policy also allows
access to list or read any Nomad service registration in the same namespace
as the job, as with the [List Services API][] or [Read Service API][].

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the code I don't think that's the case? The template block uses the job's namespace but we don't enforce that as an ACL policy. So if a workload uses the Task API it can read services in another namespace.

The current code assumes that if you have a valid WI claim that we don't need to check the namespace (ref service_registration_endpoint.go#L220). Which seems like it could have been a regression in behavior. But if I look at the original auth code from 1.3.0 (ref service_registration_endpoint.go#L437-L477) where we only had a node secret and not a WI, that's always been the policy.

I don't think this is unintentional either, as we have #14177 open which is saying "hey let's make sure the template block can do that too!"


## Workload Associated ACL Policies

You can associate additional ACL policies with workload identities by passing
Expand Down Expand Up @@ -94,3 +102,6 @@ nomad acl policy apply \
[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