You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current join token-based node attestation plugin identifies only a single node. Unlike the k8s/aws_iid node attestation, the join token does not expose any selectors, which limits us in certain aspects:
We need to create a join token request for every single node.
If we need to create a node alias from join tokens, we must track the initial SPIFFE ID assigned to each node in a separate database and then create a node alias for each of those nodes. Although one might argue that specifying a SPIFFE ID during the join token creation could act as an alias, it is challenging to create multiple node aliases for a subset of these nodes in the same node pool.
Creating and managing multiple aliases for nodes in a dynamic environment becomes operationally challenging especially when new nodes are added/removed.
Potential Solution
Create a generic plugin for JWT-based node attestation. A trusted entity that bootstraps these nodes would inject a JWT token with a specific set of labels in the claims. The agent bootstrapped with this JWT token would presented this to the server. The plugin would then verify the JWT token and expose all the claims as selectors. This enables us to create node aliases based on the selectors exposed by the plugin.
This would function similar to a Kubernetes PSAT node attestor, except that the issuer of the JWT token would be a trusted entity responsible for verifying the node before issuing the JWT tokens. To restrict arbitrary claims, we can add a template attributes on the plugin side to validate (Or we can totally ignore this and let folks write then restrictions on selectors when they create node alias entries)
We're happy to contribute back to the community if this is a good idea.
Open Questions
Are there any alternatives to solve this problem without implementing a new node attestor plugin?
Should we provide an option for the JWT token to be valid for a single attestation to ensure consistent behavior with a join token?
Problem
The current join token-based node attestation plugin identifies only a single node. Unlike the k8s/aws_iid node attestation, the join token does not expose any selectors, which limits us in certain aspects:
Potential Solution
Create a generic plugin for JWT-based node attestation. A trusted entity that bootstraps these nodes would inject a JWT token with a specific set of labels in the claims. The agent bootstrapped with this JWT token would presented this to the server. The plugin would then verify the JWT token and expose all the claims as selectors. This enables us to create node aliases based on the selectors exposed by the plugin.
This would function similar to a Kubernetes PSAT node attestor, except that the issuer of the JWT token would be a trusted entity responsible for verifying the node before issuing the JWT tokens. To restrict arbitrary claims, we can add a template attributes on the plugin side to validate (Or we can totally ignore this and let folks write then restrictions on selectors when they create node alias entries)
We're happy to contribute back to the community if this is a good idea.
Open Questions
Related Discussions
#2612
#671
The text was updated successfully, but these errors were encountered: