Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: add system authenticate bind protection policy #65

Conversation

chen-keinan
Copy link
Contributor

Following to security risk raised on system:authenticate adding a new policy to handle this case

@chen-keinan chen-keinan force-pushed the fix/add-system-authenticate-protection-policy branch from ac7d6c1 to 7dc87fb Compare January 29, 2024 10:24
@simar7 simar7 merged commit 0aac74c into aquasecurity:main Jan 30, 2024
4 checks passed
@knqyf263
Copy link

knqyf263 commented Feb 1, 2024

I don't recall if we have such logic, but can we apply this policy to only GKE clusters?

@chen-keinan
Copy link
Contributor Author

chen-keinan commented Feb 1, 2024

@knqyf263 no we can't , there is an issue to pass distribution type as rego input (will be done later). this policy is important for all distribution it is more exposable for GKE

@knqyf263
Copy link

knqyf263 commented Feb 1, 2024

this policy is important for all distribution it is more exposable for GKE

IIUC, as it is infinitely unlikely that the system:authenticated group will be assigned to an attacker in non-GKE clusters, I'm concerned that the detection of this check as CRITICAL will be noise. This could frighten many EKS and AKS users.

@chen-keinan
Copy link
Contributor Author

chen-keinan commented Feb 1, 2024

this policy is important for all distribution it is more exposable for GKE

IIUC, as it is infinitely unlikely that the system:authenticated group will be assigned to an attacker in non-GKE clusters, I'm concerned that the detection of this check as CRITICAL will be noise. This could frighten many EKS and AKS users.

the chances for system:authenticated group to by bind to a Role/ClusterRole is the same for all (GKE and non GKE) as this can be done by mistake, the problem with GKE is the generated Token which can be easily abused

@knqyf263
Copy link

knqyf263 commented Feb 1, 2024

the chances for system:authenticated group to by bind to a Role/ClusterRole is the same for all (GKE and non GKE) as this can be done by mistake

Yes, but the misconfiguration itself is not a critical problem as it's hard to get system:authenticated assigned in non GKE clusters. In most cases, non-GKE clusters are not exploitable even if system:authenticated has Role/ClusterRole. Therefore, the severity should be LOW or NOTICE (Trivy doesn't have NOTICE, though) for clusters other than GKE.

@knqyf263
Copy link

knqyf263 commented Feb 8, 2024

@chen-keinan Any comments?

@chen-keinan
Copy link
Contributor Author

@chen-keinan Any comments?

I'll change the severity to Low

@knqyf263
Copy link

knqyf263 commented Feb 9, 2024

But it is critical for GKE.

  • GKE: CRITICAL
  • Non-GKE: LOW

We want to achieve it somehow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants