projectcalico
Potential [low severity] security issue due to calico-node having serviceaccount/token permission on itself
This isn't urgent or critical, IMO, but it's worth fixing:
I commented post-merge on #6218 but filing an issue since it's more likely to be seen:
In that PR, the calico-node service account is granted serviceaccount/token permission on itself. This allows calico-node to mint tokens for calico-node. This creates a potential security issue where if an attacker could steal a token they could then 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.
Expected Behavior
Service account tokens should not be granted permission to self-perpetuate.
Current Behavior
calico-node service account is granted such permission.
Possible Solution
Use a separate service account for the CNI.
@caseydavenport
Yep, I agree. I hadn't spotted this particular issue but already have a ticket tracking this enhancement for other reasons as well: https://github.com/projectcalico/calico/issues/5921
Thanks :)
On Mon, Jul 25, 2022, 11:59 AM Casey Davenport @.***> wrote:
Yep, I agree. I hadn't spotted this particular issue but already have a ticket tracking this enhancement for other reasons as well: #5921 https://github.com/projectcalico/calico/issues/5921
— Reply to this email directly, view it on GitHub https://github.com/projectcalico/calico/issues/6421#issuecomment-1194487344, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG4TQNIX43K6WBTYOEPLILVV3P2PANCNFSM54NDD2VQ . You are receiving this because you authored the thread.Message ID: @.***>