-
Notifications
You must be signed in to change notification settings - Fork 622
Add an agent_id_parent selector to x509pop in spiffe mode #7002
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?
Changes from 2 commits
8fb6a21
d2267cf
6da3970
ac412dd
f235994
3d5166d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -313,11 +313,23 @@ | |
| return status.Errorf(codes.Internal, "failed to make spiffe id: %v", err) | ||
| } | ||
|
|
||
| selectors := buildSelectorValues(leaf, chains, sanSelectors) | ||
|
|
||
| if config.mode == "spiffe" { | ||
| agentIDStr := spiffeid.String() | ||
|
|
||
| if lastSlash := strings.LastIndex(agentIDStr, "/"); lastSlash != -1 { | ||
| parentID := agentIDStr[:lastSlash] | ||
| parentID = strings.TrimSuffix(parentID, "/") | ||
| selectors = append(selectors, "agent_id_parent:" + parentID) | ||
|
Check failure on line 324 in pkg/server/plugin/nodeattestor/x509pop/x509pop.go
|
||
| } | ||
|
Comment on lines
+319
to
+325
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a very single-use selector, for the case that you mentioned. We can publish the SPIFFE ID as the selector. For your particular case you could make the agent SPIFFE ID template be derived from the SHA1 fingerprint, to get unique SPIFFE IDs, and have the full SPIFFE ID be
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you please give an example of what the selector for the node alias would actually be in this configuration? I dont understand how it is possible with the approach your suggesting. the docs mention selectors: the san selector wont work as a spiffe svid will never have a url with x509pop. the serial number/sha1 fingerprint selectors are not useful as you will never know what it is to alias with. common name wont be defined with spiffe certs. So, there is a lack of a selector that fits the use case I think. It is ok if it is narrowly targeted a selector. it only is needed for x509 pop with spiffe mode. There are lots of selectors that only are useful for certain use cases.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The SPIFFE ID of the SVID the agent presents to spire-server to attest would be:
We'd still need to add the id as a selector so you can use in the node aliase, but that feels like a reasonable thing to do.
It's not that it's only needed for spiffe mode, it's only needed for this particular deployment. Most deployments wouldn't care about the "parent id".
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah. I see. I think that has two drawbacks.
I agree though, either way, we need a new selector. We're just debating the name of it I guess. So we could pick a name potentially independent of the rest. This does raise a discussion I wanted to have at some point about dynamic entries. This idea does kind of match an idea I've been rolling around in my head. It would be useful to simplify my own entry management, as well as potentially helping dynamic entries for spire-identity-exchange too. In most of my usage, I've run across needing to tack on the node name over and over to identifiers to guarantee uniqueness of identity. Times the number of nodes. It gets a bit painful after a while. But, what if we could set some labels on the node: we could put generic workload entries on it: Each one would use those spiffeid's for lookups and resolving workloads. but, during issuence of the svid, it would have an extra template that would resolve before issuing the final spiffeid. so it could say, append "/{{ nodeLabels.nodeName }}"
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not clear to me if the solution above is ok for you, which would mean that we'd have just an We can continue the other discussion independently of this.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If your asking if the proposed solution of just making the underlying spiffe id be the common group part, and then making them unique by adding the SHA1 fingerprint automatically to it for this special case, then no, I dont think that is a good way to solve it. It makes it too hard to:
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If I understand correctly, your proposed solution here also has a random, changing, identifier in the agent identity, the pod UUID. So that's something you have to deal with anyway. I also don't think it's that big of a deal since you're planning on using the node alias. I'm not sure it's worth adding this selector which is very specific to your deployment and is likely hard to reason about in a large deployment. The full spiffe id would be ok to have.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You keep falling back to very specific cases, designing a feature that is so specific, when the next case comes out, we're back to square one. IMO we should design features that are useful for more then just one use case so we're not constantly adding features. The way I'm using it in this particular case, yes a pod uid is somewhat unknowable up front. But, it will never change during the life of the pod. So adding it later is stable. Reboot the node unexpectedly, the pod uid stays the same. The spire-agent gets reattested, it still gets the same spiffeid while the fingerprint changes. If you really want to put a stable identity on it so you can hang off per agent entries, you use the {.Metadata.Name}} from the pod and a statefulset to give it a persistent name. Persistent identity. done. I'm not 100% sure I will never need to do that. So, why preoptimize the ability to do that completely away? Besides, we still havent addressed how your proposal will work when the fingerprint changes. That is deal breaking on its own IMO. So, I'm still at the point of, that isnt a good solution. I"m not asking for a ton of code here. We're talking for like 12 lines of code and a unit test. This really shoudlnt be burdensome on the spire team. That saves 57 lines of code https://github.com/spiffe/spire-identity-exchange/blob/main/cmd/spire-credentialcomposer-identity-exchange/main.go |
||
| } | ||
|
kfox1111 marked this conversation as resolved.
|
||
|
|
||
| return stream.Send(&nodeattestorv1.AttestResponse{ | ||
| Response: &nodeattestorv1.AttestResponse_AgentAttributes{ | ||
| AgentAttributes: &nodeattestorv1.AgentAttributes{ | ||
| SpiffeId: spiffeid.String(), | ||
| SelectorValues: buildSelectorValues(leaf, chains, sanSelectors), | ||
| SelectorValues: selectors, | ||
| CanReattest: true, | ||
| }, | ||
| }, | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.