[release-v3.23] Auto pick #5910: Use TokenRequest API instead of calico-nodes service account #6218
Conversation
…r CNI kubeconfig. With projected service account tokens in kubernetes, the service account tokens of pods are bound to the lifetime of the corresponding pod. Therefore, it may lead to problems if an external process re-uses the token of a pod. The CNI binaries used the token of calico-node. However, in case calico-node got stopped the corresponding token lost its validity and hence could no longer be used for CNI operations. Usually, this automatically resolves over time, but there are some edge cases where this is not possible, e.g. if calico-node is autoscaled in terms of resources and the new resource requests would require preemption/eviction of an existing pod the CNI operation to delete the network sandbox will fail due to the no longer valid token (as calico-node was stopped beforehand). This change switches over to using the TokenRequest API instead, i.e. creating new tokens with limited validity. It would have been good to bind the token to an object, e.g. to the corresponding node, but as of now only secret and pod are supported types for binding tokens. Hence, the tokens are only limited in time and not bound to any other kubernetes object.
caseydavenport
added
docs-not-required
✅ Deploy Preview for calico-tigera ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
✅ Deploy Preview for calico-v3-23 ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
| resources: | ||
| - serviceaccounts/token | ||
| resourceNames: | ||
| - calico-node |
There was a problem hiding this comment.
If the role containing this rule is also bound to the calico-node service account, it allows calico-node to mint tokens for calico-node. This creates a potential security issue where an attacker could steal a token and prevent their access from ever expiring by sending periodic TokenRequests for the same service account whose token they stole. Instead, it would be better to grant calico-node permission to request tokens for a separate service account that the CNI is intended to run as. For example, grant calico-node permission to mint tokens for a calico-node-cni service account, and grant calico-node-cni the permissions that the CNI needs. That way, no tokens have the ability to self-perpetuate.
There was a problem hiding this comment.
Yep, I agree. I hadn't spotted this particular issue but already have a ticket tracking this enhancement for other reasons as well: #5921
Cherry pick of #5910 on release-v3.23.
#5910: Use TokenRequest API instead of calico-nodes service account
Original PR Body below
Description
Use TokenRequest API instead of calico-nodes service account token for CNI kubeconfig.
With projected service account tokens in kubernetes, the service account tokens of pods
are bound to the lifetime of the corresponding pod. Therefore, it may lead to problems
if an external process re-uses the token of a pod.
The CNI binaries used the token of calico-node. However, in case calico-node got stopped
the corresponding token lost its validity and hence could no longer be used for CNI
operations. Usually, this automatically resolves over time, but there are some edge cases
where this is not possible, e.g. if calico-node is autoscaled in terms of resources and
the new resource requests would require preemption/eviction of an existing pod the CNI
operation to delete the network sandbox will fail due to the no longer valid token
(as calico-node was stopped beforehand).
This change switches over to using the TokenRequest API instead, i.e. creating new
tokens with limited validity. It would have been good to bind the token to an object,
e.g. to the corresponding node, but as of now only secret and pod are supported types
for binding tokens. Hence, the tokens are only limited in time and not bound to any
other kubernetes object.
Related issues/PRs
fixes #4857
fixes #5712
Todos
Release Note
Reminder for the reviewer
Make sure that this PR has the correct labels and milestone set.
Every PR needs one
docs-*label.docs-pr-required: This change requires a change to the documentation that has not been completed yet.docs-completed: This change has all necessary documentation completed.docs-not-required: This change has no user-facing impact and requires no docs.Every PR needs one
release-note-*label.release-note-required: This PR has user-facing changes. Most PRs should have this label.release-note-not-required: This PR has no user-facing changes.Other optional labels:
cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.