add proposal about container-level serviceaccount #2497
Conversation
k8s-ci-robot
added
size/S
k8s-ci-robot
added
the
cncf-cla: yes
WanLinghao
changed the title
| Path string | ||
| // IsContainerLevel determines if the token should include information about | ||
| // which container the request comes from. | ||
| IsContainerLevel bool |
There was a problem hiding this comment.
this would mean the kubelet would have to fan out and maintain N tokens for a pod with N containers... is that what we want?
There was a problem hiding this comment.
@liggitt For most use cases who don't need container-level serviceaccount feature, they just launch a token projection volume with IsContainerLevel being false. In this case, all the containers could share single serviceaccount token.
There was a problem hiding this comment.
I'd recommend considering this as an improvement after the token projection feature graduates, but will defer to @mikedanese who is driving that work
| object will be embedded as claims in the issued token. A token bound to an | ||
| object will only be valid for as long as that object exists. | ||
| object will only be valid for as long as that object exists. The token will contain | ||
| which container the request comes from if ContainerName was specified. ContainerName |
There was a problem hiding this comment.
without a consistent enforcement mechanism to guarantee these tokens are only used in requests from that container, I don't think we can make that claim
There was a problem hiding this comment.
kubernetes/kubernetes#61858 insert pod information into user.Info.Extra() , and we could not make sure the tokens are only used in requests from that pod neither. So what's the difference between the container information and pod information. I am a little confused about this.
There was a problem hiding this comment.
those assert what pod the token was created for, they do not assert that is where the request is coming from
WanLinghao
force-pushed
the
container_sa
branch
from
455bf14 to
268b33e
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: WanLinghao If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@liggitt I have improved the description as you commented, PTAL |
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
k8s-ci-robot
added
the
lifecycle/stale
|
@WanLinghao what are some good use cases which require per container service account tokens which cannot be fulfilled by separating those containers into different pods ? It would be good to highlight those. Also it would be good to start a different KEP if this makes sense . |
|
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
k8s-ci-robot
added
lifecycle/rotten
|
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
|
@fejta-bot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
5 participants
add description about container-level serviceaccount, it could be useful when user want to
give containers different api-server access. The basic idea is make serviceaccount token acquired
by token projected volume contains container name. Authorizer would use this info with pod-name, pod-uid together to confirm which <pod, container> the request comes from.
ref:
kubernetes/kubernetes#66020
kubernetes/kubernetes#61858