Restrict RBAC Admins – OPA Gatekeeper RBAC Guardrail (Part 2)

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]