Here in this blog, we will share some important information about Clusters Securities and preventing malicious access from the outer world with Kubernetes. But before going for securities, let us take a look at Kubernetes first! Kubernetes, is an automating, open source system originally developed by the Google team in 2014 and heavily influenced by Google’s Borg system for its complex structuring and architecture. Kubernetes is a container orchestration platform to maintain large scale of clusters with its intelligent security keys. As the cluster is the main space in our project, it’s become quite essential to protect it from outer approach.
So, let’s start with the main terms and conditions to have a secured cluster:
In the beginning:
The beginning part is much more crucial; as the entire future processing and a scope relay on the initial setup. In this you need a Kubernetes cluster with a kubectl command-line to communicate with your cluster in the start. In case you don’t have a cluster, then you can either create one using “Minikube”, “Katacoda” or “Play with Kubernetes”. And don’t forget to check your Version by entering command line “kubect1 version”.
– Minibuke Installion:
For installing Minikube check: VT-x or AMD-v virtualization must be enabled in your computer’s BIOS.
In case you want to change the VM then add the –vm-driver=xxx and flag to minikube start.
– For Katacoda Installation:
Command line to launch cluster: launch.sh
Using WeaveNet it will create two node cluster for networking.
If you are all setup with these three installation with your cluster then we are ready to secure it with Kubernetes.
Controlling access to the Kubernetes Api:
Kubernetes is a fully auto driven API program and by controlling access of its boundaries one can achieve its initial security from all kinds of external penetrations.
Usage of TLS for API traffic:
Due to the Kubernetes API driven behavior, it expects all APIs in Cluster needs to the crypt with TLS by default, with thismost of the installed methods will allow certifications and authentications to cluster in return. This is the reason admin should be familiar with each component setting to understand the difference between secure and unsecure traffic.
Authenticating APIs:
A common mechanism in APIs calling for a cluster is a crucial thing, to draw a line of defense! It will help programmers choose frequent commands for single users and larger clusters like integrating an existing OIDC or LDAP server, etc,. One can also authorize their APIs setup via given commands:
Because HTTP requests are made to the API server, plugins attempt to follow with the request:
– Username: String to identify the end user. Kube-admin, UID, Groups and Extra fields.
One can use this to enable multiple authentication methods as well. You should at least use two methods:
– service tokens – service accounts
– One method at least – user authentication.
Now the last system:authenticated group is there in the entire list of authenticated users.
Apart from this X509 Client Certs, Static Token File, Bootstrap Tokens, etc. are also must consider ones.
API Authorization:
After APIs authentication, every single API call should pass a tailor made authorization! The RBAC as (Role-based Access Control) is a Kubernetes component to match all single and groups of users from a established set of permissions also called permission bundles with a merge of Verbs with Resources.
The RBAC uses the “rbac.authorization.k8s.io” API group to run authorize decisions, allowing admins for dynamic configurations through Kubernetes API.
Use –authorization-mode=RBAC to enable RBAC and start your server command given command line.
Note: It is highly recommended to use Node and RBAC authorizers side by side, in with the NodeRestriction plugin.
These command functions are enough for smaller clusters only, but with the increasing line of users it may become necessary to use distinguish teams and namespaces with limited roles.
Controlling Access To Kubelet:
As discussed above, the Kubelets is a AP driven program that exposes HTTPS endpoints and grants control on the node of the containers which reults in the unauthenticated access to the API.
1) To make anonymous access disable and send 401 Unauthorized to unauthenticated requests:start kubelet with –anonymous-auth=false flag command.
2) Enable X509 client certificate authorization to the HTTPS end point:start kubelet with command –client-ca-file flag, to enable a CA bundle to verify certificates. start apiserver command with –kubelet-client-certificate and –kubelet-client-key flags
3) Now enable API bearer tokens to authenticate to the Kubelet HTTPS end point:
– make sure the authentication.k8s.io/v1beta1 API group is enabled.
– start kubelet with command –authentication-token-webhook, –kubeconfig, and –require-kubeconfig flags.
Controlling The Capabilities Of A Workload Or User At Runtime:
Installing and controlling policies leads to more powerful controls. These controlling policies, implement to limit the use case like how objects act on the cluster and other resources.
Controlling what privileges containers run with:
In this we use Pod definition and the Pod definition contains Pod-Security-Policies! Pod security policies are used to limit the volume mounts, especially in the case of hostPath. To establish security in setting for a Pod, mention the securityContext in the Pod specification. In this the securityContext is a PodSecurityContext object.
The configuration file for a Pod that has a securityContext and an emptyDir volume: and few steps to create your own pod:
– Create the Pod: kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/security-context.yaml
– Verify that the Pod’s Container is in run time: kubectl get pod security-context-demo
– Set a shell to running Container: kubectl exec -it security-context-demo — sh
– List all the runtime process:ps aux
– Mention In shell, navigate to /data, one directory:cd /data ls -l
– To navigate to /data/demo, do create a file: cd demo echo hello > testfile
– Exit shell: exit
Apart from these main features of securing, one can also use other listed categories too!
Limiting resource usage on a cluster, Restricting network access, Restricting cloud metadata API access And Controlling which nodes pods may access.
We hope that this information will suit your queries prescribed and help you to come up with good experience in securities and presentations of Kubernetes securities. For better results, please follow each step sequentially!
Controlling the capabilities of a workload or user at runtime
Protecting cluster components from compromise
