Cross-cluster delegation¶

Use case¶

I have a user account on cluster A. I would like to run a container on cluster B, using data from cluster C. (Or more generally, I'd like to give cluster B a limited ability to perform an operation on C on my behalf, e.g. a "role").

Design sketch¶

I have a federated identity. I have user accounts on clusters B and C which are linked to cluster A.

I have a token issued by A. I can "salt" the token and use it to access B and C as my identity from A.

1. Make an API call to create a new token T on A, with restricted scope on A. Also add "cluster scope" eg which other clusters are authorized to recognize this token.
2. Salt the token T to get s(C, T). Make an API call to cluster C to restrict the scope of token s(C, T).
3. Create a container request on B. Specify that the container will use token T (provided unsalted) for auth_uuid (instead of getting a generated one).
4. The container contacts cluster C, it computes s(C, T) to get the token.
5. From the prior operation, the token s(C, T) has limited scope.
6. The container cannot use this token on another cluster because the "cluster scope" means the other clusters will deny it.

Assumptions:

The client always salts tokens when using them to contact a cluster other than the home cluster associated with the token. We have to provide an unsalted auth token to run the container because the container client code will need to salt it to contact the other clusters.