In this series of blog posts, we will be looking at deploying OPA gatekeeper as the admission controller for our Kubernetes cluster. We will be focusing specifically on creating gatekeeper policies for RBAC (Role Based access controls) in the Kubernetes cluster.
If you want to know how the Audit logs are sent to EFK, you can read the following article on sending the logs to EFK.
Aim :
Restrict Users who can Manage Roles and Cluster Roles.
We will be creating a policy which will only allow only specific users to manager Roles and Cluster Roles.
template.yaml
apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8sroleauth spec: crd: spec: names: kind: K8sRoleAuth validation: openAPIV3Schema: properties: users: type: array items: type: string targets: - target: admission.k8s.gatekeeper.sh rego: | package k8sroleauth violation[{ "msg": msg}]{ input.review.object.kind == "RoleBinding" input.review.object.roleRef.name == "role-manager" name := input.review.object.subjects[_].name allowed_names := input.parameters.users[_] not contains(allowed_names,name) msg := "not allowed" }
Let’s have a look at the REGO policy
- input.review.object.kind == “RoleBinding” – Checks if the kind is ‘RoleBinding’
- input.review.object.roleRef.name == “role-manager” – Checks if the roleRef is ‘role-manager’. (It can be anything that you defined while creating the role).
- name := input.review.object.subjects[_].name – Checks all the names in the subjects array and stores it inside the ‘name’ variable.
- allowed_names := input.parameters.users[_] – Saves the ‘users’ mentioned in parameters from our constraint to the ‘allowed_names’ variable.
- not contains(allowed_names,name) – Checks if the names provided are present in the allowed names from constraints.
constraint.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRoleAuth metadata: name: block-users spec: match: kinds: - apiGroups: ["rbac.authorization.k8s.io"] kinds: ["*"] parameters: users: - "sid"
The parameters ‘users’ can have multiple values of usernames.
RBAC-deny.yaml
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: role-binding subjects: - kind: User name: mike apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: role-manager apiGroup: rbac.authorization.k8s.io
RBAC-allow.yaml
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: role-binding subjects: - kind: User name: sid apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: role-manager apiGroup: rbac.authorization.k8s.io
In this article, we saw how we can restrict the Role and ClusterRole management to specific users. We will be looking at more such RBAC policies in future posts.
Other related articles:
- Restrict Wildcards in RBACs – OPA Gatekeeper RBAC Guardrail (Part 3)
- A Series of Blog Posts on using OPA Policies & Gatekeeper for Kubernetes Security.
Practice here:
https://www.katacoda.com/cloudsecops/courses/opagatekeeper-policy/managerole
References:
- https://github.com/open-policy-agent/gatekeeper
- https://github.com/open-policy-agent/gatekeeper-library
Thank you for reading! – Siddarth Tanna 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