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 Network Policy inside the Kubernetes cluster.

If you want to push the gatekeeper Audit logs to EFK, you can read the following article  on sending  logs to EFK.

Why do we need it ?

Before we move forward with the OPA gatekeeper, we will first look at RBAC. Role-based access control in Kubernetes, allows you to restrict the actions that can be performed by a particular user inside the cluster.  This allows us to follow the ‘principle of least privilege’.

Please note, there are two types of roles that can be assigned to a user. One is a ‘ClusterRole’ which gives permissions to do things on the entire cluster whereas the ‘Role’  is restricted to a namespace.

Creating a user in the network namespace.

kubectl config set-context network-context  \
--cluster=minikube \ 
--namespace= network \
--user= sid

We create a new context ‘network-context’ which points to the network namespace with the user as sid.

Now, let us create a role for the user.

Role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
        name: network-admin
        namespace: network
rules:
        - apiGroups: ["networking.k8s.io"]
          resources: ["networkpolicies"]
          verbs: ["list","create","get"]

Here,

  • apiGroups will represent the api being used.
  • resources will define the resources in the api to be allowed access to.
  • verbs define the list of actions that are allowed to be performed.

To learn more about different ways you can perform auditing and logging in the Kubernetes cluster, you can read the official documentation.

RoleBinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
        name: network-role
        namespace: network
subjects:
        - kind: User
          name: sid
          apiGroup: rbac.authorization.k8s.io
roleRef:
        kind: Role
        name: network-admin
        apiGroup: rbac.authorization.k8s.io

We first created a role, and then role binding will define the users to which the roles will be assigned to. 

Here,  in the subjects array, we define the user name. 

The roleRef defines the kind and the name of the role to be assigned. 

Now, let us try to see if the user ‘sid’ can create or list any network policy in the network namespace without creating the rule first.

Check permissions for the user.

We can see that the user ‘sid’ is denied from listing or creating any network policy in the ‘network’ namespace. Now, let’s create the role.

Create the role.

When we try to create or list the networkpolicies now, we are not deined.

Check the permissions again.

We can see that the user can successfully create or list network policies inside the ‘network’ namespace. 

RBAC can be applied in many different ways. A network admin can even be given the permission to apply and list networking policies throughout the cluster in all namespaces. This was a very basic example of RBAC and how you can limit users from performing restricted actions.  For more information please refer to the official Kubernetes documentation.

Next, we will be looking at how even after having the privileges to create or delete certain resources, we can add extra layers of security by restricting privileged users from performing certain actions.

Other Related articles:

Practice here:

https://www.katacoda.com/cloudsecops/courses/opagatekeeper-policy/managerole

References:

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

Leave a Reply

%d bloggers like this: