Preventing “Sys:All” vulnerability from ruining your day

Preventing “Sys:All” vulnerability from ruining your day

nirmata sys all blog v4

Google Kubernetes Engine (GKE) is a popular tool for managing containerized applications. However, a critical vulnerability has been discovered in GKE that could allow attackers to take control of a Kubernetes cluster. The vulnerability is called “Sys:All” and is caused by a misunderstanding of the “system:authenticated” group.

What is the attack vector?

The “system:authenticated” group is a default Kubernetes group that includes any authenticated Google account. This means that any Google account, not just verified users within an organization, can be used to gain access to a Kubernetes cluster. Attackers can exploit this vulnerability by using a Google account to authenticate themselves and then gain access to perform malicious activities.

How do we remediate it?

Google has taken steps to fix the most severe exploit in newer GKE versions, but many clusters remain vulnerable. To protect your clusters, you can use the Kyverno policy that restricts the use of the groups necessary to exploit “Sys:All.” This policy blocks the binding of ‘cluster-admin’ to the specific vulnerable groups/users: system:authenticated, system:unauthenticated, and system:anonymous. 

kind: ClusterPolicy
  name: restrict-clusteradmin-rolebindings
  validationFailureAction: Enforce
  - name: validate-restricted-cluster-admin-bindings
        - ClusterRoleBinding
        - RoleBinding
      message: "Binding ClusterRole 'cluster-admin' is restricted, system:authenticated, system:unauthenticated and system:anonymous are not allowed."
          - key: "{{ request.object.subjects[].name }}"
            operator: AnyIn
            - system:authenticated
            - system:unauthenticated
            - system:anonymous 
         - key: "{{ }}"
           operator: Equals
           value: "cluster-admin"

With the policy in place, we can now ensure that cluster-admin can no longer assume the vulnerable groups and users.

# cat cluster-role.yaml
kind: ClusterRoleBinding
  name: good-clusterrolebinding
  kind: ClusterRole
  name: cluster-admin
- apiGroup:
  kind: Group
  name: system:authenticated
- apiGroup:
  kind: Group
  name: system:unauthenticated
- apiGroup:
  kind: User
  name: system:test2

# kubectl apply -f cluster-role.yaml
Resource: ", Resource=clusterrolebindings", GroupVersionKind: ", Kind=ClusterRoleBinding"
Name: "good-clusterrolebinding", Namespace: ""
for: "cluster-role.yaml": error when patching "cluster-role.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:

resource ClusterRoleBinding//good-clusterrolebinding was blocked due to the following policies

  validate-restricted-cluster-admin-bindings: Binding ClusterRole 'cluster-admin'
    is restricted, system:authenticated, system:unauthenticated and system:anonymous
    are not allowed.


It is crucial to implement least-privilege access control practices for Kubernetes to prevent such vulnerabilities. While there are currently no known widespread attacks using this vulnerability, experts warn that it’s just a matter of time. Therefore, it is highly recommended that you take action now and protect your Kubernetes clusters from potential attacks.

If you are interested in modernizing and automating security with policy as code, check out Nirmata’s Policy Manager and reach out to set up a deep dive!

Locked Doors, Untrusted Keys: Securing Containers in the Wake of Leaky Vessel Vulnerabilities
Enhancing Application Security with Policy-as-Code
No Comments

Sorry, the comment form is closed at this time.