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.
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.
When we try to create or list the networkpolicies now, we are not deined.
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:
- OPA Gatekeeper Restrict Namespaces for Pod Networking – OPA Gatekeeper NetworkPolicy Guardrail (Part 2 )
- A Series of blog posts on using OPA Policies and 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