How to Harden your K8s Cluster

Hardening a Kubernetes cluster for production involves implementing a comprehensive set of security best practices to protect your cluster from vulnerabilities and attacks. 

organizations deploy and run their applications, and it has created a significant shift in mindsets. While Kubernetes has already gained a lot of popularity and more and more organizations are embracing the change, running Kubernetes in production requires care.

Although Kubernetes is open source and does it have its share of vulnerabilities, making the right architectural decision can prevent a disaster from happening.

You need to have a deep level of understanding of how Kubernetes works and how to enforce the best practices so that you can run a secure, highly available, production-ready Kubernetes cluster. Although Kubernetes is a robust container orchestration platform, the sheer level of complexity with multiple moving parts overwhelms all administrators. That is the reason why Kubernetes has a large attack surface, and, therefore, hardening of the cluster is an absolute must if you are to run Kubernetes in production.

I will describe a few best practices that you can adopt if you are running Kubernetes in production. Let’s find out.

Controlling Access in Kubernetes with RBAC

In Kubernetes, RBAC (Role-Based Access Control) is a security system used to control who can access what resources within the cluster. It works by assigning permissions to users, groups, and service accounts based on their roles within the organization.

RBAC is a method of regulating access to computer resources based on the roles of individual users within an organization. Within Kubernetes, It is a key security control to ensure that cluster users and workloads only have access to the resources they need. It lets you create fine-grained permissions to manage what actions users and workloads can perform on resources. 

·  Roles: Define what actions (like viewing, creating, or deleting) can be performed on different resources (like pods, services, or nodes).

·  RoleBindings: Link these roles to the actual users, groups, or service accounts, granting them the specified permissions

RBAC Explained 

Imagine you're the owner of a large office building, and within this building, there are different rooms—some hold sensitive information, like the finance department, while others are more general, like the break room. You wouldn't want everyone to have access to every room, especially not the sensitive areas, unless they have a legitimate reason to be there. This is where RBAC, or Role-Based Access Control, comes into play in the world of computer systems, particularly in environments like Kubernetes.

RBAC (Role-Based Access Control) is like giving out keys to different rooms in your building based on the role each person holds within your company:

• Roles: These are specific sets of permissions that you define. For example, you might have a 'Manager' role that allows entry into financial records rooms, or a 'Staff' role that only allows access to general working areas and the break room. In Kubernetes, these roles define what operations a user, or a service running in the cluster, can perform on various resources (like pods, services, and more).
• Users and Service Accounts: Think of these as the employees or services that perform tasks within your building. In Kubernetes, these can be actual users (like administrators or developers) or automated users (like a running application), known as service accounts.
• Bindings: This is akin to you assigning a keycard loaded with specific access permissions to a person. In Kubernetes, a 'RoleBinding' or 'ClusterRoleBinding' links a role to users and service accounts, granting them the permissions defined in the role.

Practical Example in an Office Setting

Let's say you have a new manager, Alice. You decide Alice needs access to financial records, the employee database, and the management meeting room:

1. Create a Role for managers that includes the ability to read financial documents, access the employee database, and enter the management meeting room.
2. Assign Alice to the Manager Role using a RoleBinding, effectively giving her a keycard that grants her access to all these areas.

Why Use RBAC?

Security and Efficiency: RBAC helps ensure that only the right people have the right access. This not only secures sensitive information but also makes operations more efficient. People don’t accidentally wander into areas or modify settings they shouldn’t, reducing errors and potential security risks.

Simplicity and Scalability: As your company grows, it's easy to manage permissions. Instead of figuring out permissions for each new employee, you simply assign them to a role that already has the necessary permissions defined.

In summary, RBAC is about creating a secure and organized environment by ensuring that people (or automated services) have access only to the resources they need to do their jobs, nothing more and nothing less. It’s a way to keep your organizational “building” orderly and secure.

In this lab, you will have the opportunity to practice your skills with the Kubernetes RBAC system by implementing your own RBAC permissions to appropriately limit user access.

To create an RBAC policy that prevents anyone, including the Kubernetes master, from listing deployments in the dev namespace, you need to:

1. Create a ClusterRole that denies access to list deployments.
2. Create a RoleBinding in the dev namespace that binds all users to this ClusterRole.

Here's how you can do it:

1. Create a Role for the dev User

vi deny-list-deployments-clusterrole.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deny-list-deployments
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["list"]

 

Apply the ClusterRole configuration:

kubectl apply -f deny-list-deployments-clusterrole.yaml

2. Create a RoleBinding in the dev Namespace

Next, create a RoleBinding in the dev namespace that binds all users to this ClusterRole. This will effectively deny everyone the ability to list deployments in the dev namespace.

vi deny-list-deployments-rolebinding.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: deny-list-deployments
  namespace: dev
subjects:
  - kind: Group
    name: system:authenticated
    apiGroup: rbac.authorization.k8s.io
  - kind: Group
    name: system:unauthenticated
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: deny-list-deployments
  apiGroup: rbac.authorization.k8s.io

 kubectl apply -f deny-list-deployments-rolebinding.yaml

Verify the  user cannot list deployments:

 kubectl get deployments -n dev

We'll get an error, which is what we want.