Introduction

This is the last post in this series about OPA policies under the category “CI/CD and Secure Configurations”. This is not related to OPA and is quite different from the other articles. We’ll look into a policy to deny the pod “exec” resource to prevent unauthorized users from running commands inside a container.

What is a RBAC?

To put it in simple terms, Role-Based Access Control in Kubernetes is used to restrict access to various resources. Managing all the permissions to the resources are done by creating a Role or a ClusterRole. The process is as follows:

  • We create a “Role” or a “ClusterRole” which describes the permissions to the resources.
  • Now we associate the created “Role” or the “ClusterRole” through “RoleBinding” or “ClusterRoleBinding” respectively to one or more users.

Why do we need this policy?

Though this can be used to restrict any resource, we’ll focus on preventing unauthorized  access to the “exec” resource. “kubectl exec” is a very handy command used to execute inside containers and is often used by many developers to inspect and debug their applications. The main reason to restrict access is to prevent attackers from executing malicious payloads.

Deny Pod “Exec” Resource

role-non-violation.yaml

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: block-exec
rules:
- apiGroups: ["*"]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "create", "delete", "edit"]

The “verbs” is used to provide access like “get”, “watch”, “create” etc. Here, we have allowed everything except “exec”. Now we have to bind the role to a user(s) that we created.

bind.yaml

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: user1-get-pods
subjects:
- apiGroup: ""
  kind: User
  name: user1
roleRef:
apiGroup: ""
kind: Role
name: block-exec

We have to make sure that the “name” under “roleRef” should be the same as the name of the role in the “role.yaml” file.

Applying both the files in the same order will create a role with the permissions given in the “role.yaml” file and binds it to a user(s) mentioned in the “bind.yaml” file. The role file can be modified according to our needs to restrict access to any resources.

role-violation.yaml

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: block-exec
rules:
- apiGroups: ["*"]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "create", "delete", "edit"]

On applying the “role-violation.yaml” and the “bind.yaml”, we can see that this role wont be created as “exec” is among the list of the verbs allowed.

Conclusion

We should always restrict access to all the resources based on a user’s requirement instead of just giving access to all the resources, especially the pod “exec” resource, as it is often used by attackers to execute malicious code and get a shell inside containers.

Other related articles:

References:

Thank you for reading! – Vishal Pranav and Setu Parimi

Sign up for the blog directly here.

Check out our professional services here.

Feedback is welcome! For professional services, fan mail, hate mail, or whatever else, contact [email protected]


0 Comments

Leave a Reply

%d bloggers like this: