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.

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

Support for JWT Token based Node Attestation #5647

Open
snanjundaswamy opened this issue Nov 13, 2024 · 0 comments
Open

Support for JWT Token based Node Attestation #5647

snanjundaswamy opened this issue Nov 13, 2024 · 0 comments

Comments

@snanjundaswamy
Copy link

snanjundaswamy commented Nov 13, 2024

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:

  1. We need to create a join token request for every single node.
  2. 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.
  3. 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

  1. Are there any alternatives to solve this problem without implementing a new node attestor plugin?
  2. Should we provide an option for the JWT token to be valid for a single attestation to ensure consistent behavior with a join token?

Related Discussions

#2612
#671

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant