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.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-clusteradmin-rolebindings
spec:
validationFailureAction: Enforce
rules:
- name: validate-restricted-cluster-admin-bindings
match:
resources:
kinds:
- ClusterRoleBinding
- RoleBinding
validate:
message: "Binding ClusterRole 'cluster-admin' is restricted, system:authenticated, system:unauthenticated and system:anonymous are not allowed."
deny:
conditions:
all:
- key: "{{ request.object.subjects[].name }}"
operator: AnyIn
value:
- system:authenticated
- system:unauthenticated
- system:anonymous
- key: "{{ request.object.roleRef.name }}"
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
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: good-clusterrolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:authenticated
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:unauthenticated
- apiGroup: rbac.authorization.k8s.io
kind: User
name: system:test2
# kubectl apply -f cluster-role.yaml
Resource: "rbac.authorization.k8s.io/v1, Resource=clusterrolebindings", GroupVersionKind: "rbac.authorization.k8s.io/v1, 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
restrict-clusteradmin-rolebindings:
validate-restricted-cluster-admin-bindings: Binding ClusterRole 'cluster-admin'
is restricted, system:authenticated, system:unauthenticated and system:anonymous
are not allowed.
Conclusion
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!
Sorry, the comment form is closed at this time.