-
Notifications
You must be signed in to change notification settings - Fork 2k
wi: new endpoint for listing workload attached ACL policies #25588
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.
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
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: Tim Gross <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good to make sure we present enough data to determine whether the policy is applied at the job/group/task level, and it looks like this is potentially covered.
@pkazmierczak is this going into the 1.10 release? |
no, this is not going into 1.10.
|
}, | ||
"ModifyIndex": 26, | ||
"Name": "nomad-policy", | ||
"Rules": "# Allow read only access to the default namespace\nnamespace \"default\" {\n policy = \"read\"\n}\n\n# Allow writing to the `foo` namespace\nnamespace \"foo\" {\n policy = \"write\"\n}\n\nagent {\n policy = \"read\"\n}\n\nnode {\n policy = \"read\"\n}\n\nquota {\n policy = \"read\"\n}\n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find myself right away also wanting this for non-WI tokens. I know that I can do nomad acl token self
, then look at the Policies/Roles, then go inspect those (if I have permission?), but seeing the rules this clearly in a single API call is quite nice (if perhaps a bit of a security concern...)
if the command name was more specific, like nomad acl workload-identity-policy self
then I wouldn't have this expectation, but I feel this new command has the same issue as "why doesn't nomad acl token self
tell me about my WI token?" only in reverse: "why doesn't nomad acl policy self
tell me about my ACL policy?"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, having nomad acl token self
and nomad acl policy self
both work for both WI and ACL Tokens really seems like the most intuitive behavior.
Anyone wanting an easy way to try this out (after building locally):
namespace "shared" {
variables {
path "*" {
capabilities = ["read"]
}
}
}
job "wi-policy" {
type = "batch"
group "g" {
restart { attempts = 0 }
reschedule { attempts = 0 }
task "t" {
driver = "raw_exec"
config {
command = "bash"
args = ["-xc", "nomad acl policy self; nomad acl policy self -json"]
}
env {
NOMAD_ADDR = "unix:${NOMAD_SECRETS_DIR}/api.sock"
}
identity {
env = true
}
}
}
}
|
@@ -66,7 +66,17 @@ func (c *ACLTokenSelfCommand) Run(args []string) int { | |||
// Get the specified token information | |||
token, _, err := client.ACLTokens().Self(nil) | |||
if err != nil { | |||
c.Ui.Error(fmt.Sprintf("Error fetching self token: %s", err)) | |||
if !strings.Contains(err.Error(), "Unexpected response code: 404") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this bool check is reversed, because this is what happens when I use a non-existent token in current main
:
$ NOMAD_TOKEN=10000000-0000-0000-0000-000000000000 nomad acl token self
Error fetching self token: Unexpected response code: 404 (ACL token not found)
if !strings.Contains(err.Error(), "Unexpected response code: 404") { | |
if strings.Contains(err.Error(), "Unexpected response code: 404") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 I don't follow, Daniel.
On main
you will of course get 404 if you try to query token self
with WI. What you're showing above is strange to me, prefixing nomad acl token self
with a bogus token should give you 403 instead.
The conditional here is correct, though. For any error other than 404, we return error. In case we get 404, we further check job-attached policies, and only if we cannot find any, we say: no acl token and no policies attached.
Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what exactly I was thinking back then is lost to the mists of time, alas.
but, while I'm here comparing the two error messages from a bad, but valid (uuid), ACL token:
-
nomad release 1.10 is clearly about one thing:
Error fetching self token: Unexpected response code: 404 (ACL token not found)
-
this pr:
No ACL tokens or ACL policies attached to a workload identity found.
the new one seems to me like acl token self
is only for workload ID, because I don't parse "or ACL policies attached to a workload identity" as a separate item? I get lost grammatically somewhere along the way before hitting "found" and I parse it as "No ... workload identity found."
this might be resolved for me with a single character:
No ACL tokens
nor
ACL policies attached to a workload identity found.
for bonus clarity, if a bit choppy in rhythm:
No ACL tokens,
nor
ACL policies attached to a workload identity, found.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a really nice feature, and thanks @gulducat for quick local testing policy/job!
command/agent/acl_endpoint.go
Outdated
// Resolve policies for workload identities | ||
policyReply := structs.ACLPolicySetResponse{} | ||
if err := s.agent.RPC("ACL.GetClaimPolicies", &policyArgs, &policyReply); err != nil { | ||
return nil, err | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My objection to this API as it stands is that we're only presenting the ACL policies for Workload Identity claims but the API is /v1/acl/policy/self
. Ignoring unifying the CLI output for the moment, either (a) this API should retrieve policies for any authenticated request or (b) it should be under a different route than /v1/acl/policy/self
or (c) the RPC handler should be changed to cover both ACL tokens and WI claims. Unfortunately it looks like we shipped the RPC handler as-is and now it would be awkward to retrieve ACL token policies there. So I think (a) is my preferred option, but we'd need to split the API to send to different RPC handlers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
4053a48 implements option (a), but then we end up with a bit of a mess, because GetClaimPolicies
and ListPolicies
RPCs return different types (maps or slices, respectively). I thought perhaps the key in the map is the WI name, but it's just policy name, so I'll follow-up with a change that just returns a list of ACLPolicyStub
to get a unified output.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah but then we'd lose some data that's useful for WI-attached policies if we only return ACLPolicyStub
:/
// ACLPolicyListStub is used to for listing ACL policies
type ACLPolicyListStub struct {
Name string
Description string
Hash []byte
CreateIndex uint64
ModifyIndex uint64
}
This doesn't contain JobACLs or Rules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for creating the docs content! I left a few style nits.
The `acl policy self` command is used to fetch information about the currently | ||
set ACL policies attached to the workload. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The `acl policy self` command is used to fetch information about the currently | |
set ACL policies attached to the workload. | |
The `nomad acl policy self` command fetches information about the currently | |
set ACL policies attached to the workload. |
Style nit: use active voice
|
||
## Examples | ||
|
||
Fetch information about an existing ACL policies attached to the workload: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fetch information about an existing ACL policies attached to the workload: | |
Fetch information about an existing ACL policies attached to the workload. |
FYI the style guide wants us to introduce a code block with a descriptive, imperative sentence that ends with a period.
@@ -40,3 +40,13 @@ Modify Index = 8 | |||
Policies = n/a | |||
Roles = n/a | |||
``` | |||
|
|||
The command will also detect if the current Nomad token is a workload identity |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The command will also detect if the current Nomad token is a workload identity | |
The command also detects if the current Nomad token is a workload identity |
style nit: use present tense
@@ -40,3 +40,13 @@ Modify Index = 8 | |||
Policies = n/a | |||
Roles = n/a | |||
``` | |||
|
|||
The command will also detect if the current Nomad token is a workload identity | |||
JWT and respond with a hint if that's the case: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JWT and respond with a hint if that's the case: | |
JWT and respond with a hint if that's the case. |
|--------|-----------------------|--------------------| | ||
| `GET` | `/v1/acl/policy/self` | `application/json` | | ||
|
||
The table below shows this endpoint's support for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The table below shows this endpoint's support for | |
This table shows this endpoint's support for |
style nit: we avoid using "below" or "above"
This introduces a new HTTP endpoint (and an associated CLI command) for querying
ACL policies associated with a workload identity. It allows users that want
to learn about the ACL capabilities from within WI-tasks to know what sort of
policies are enabled.
Fixes #24663
Internal ref: https://hashicorp.atlassian.net/browse/NMD-423
(reviewers: this requires #25547 to work)