Potential [low severity] security issue due to calico-node having serviceaccount/token permission on itself

[mtaufen]

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

[mtaufen]

@mikedanese in case you have thoughts on other solutions

[caseydavenport]

Yep, I agree. I hadn't spotted this particular issue but already have a ticket tracking this enhancement for other reasons as well: #5921

[mtaufen]

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 <#5921> — Reply to this email directly, view it on GitHub <#6421 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG4TQNIX43K6WBTYOEPLILVV3P2PANCNFSM54NDD2VQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>