Basics of Kubernetes security
An introduction to important Kubernetes security components
Kubernetes is popular among developers and administrators, and the concepts of deploying, scaling, and managing containerized applications are very familiar. However, when production deployments are discussed, one area of Kubernetes that is critical to production deployments is security. It’s important to understand how the platform manages authentication and authorization of users and applications.
If your Kubernetes cluster holds sensitive information such as bank account details, medical records, or anything confidential, you should take advantage of all the security precautions that Kubernetes offers. In addition, you can use plenty of non-Kubernetes-specific security tools and approaches to add extra security layers.
Important components of Kubernetes security
The Kubernetes API server (
kube-apiserver) is the component that receives all the incoming requests. The incoming requests are processed to modify the state of the cluster. All requests in Kubernetes originate from:
- External users
- Service accounts
- Kubernetes components
But before reaching
kube-apiserver, there are security components that help to bring in security measures to your application. Following are the components which will help you to secure your Kubernetes application:
- Admission controllers
Figure 1 shows the Kubernetes workflow diagram. After the request moves through the authentication modules, authorization modules, and admission controller, then the request is processed.
Figure 1. Kubernetes workflow
If the origin of a request is unknown, Kubernetes treats it as an anonymous request. Depending on the configuration of the components, the authentication modules may allow or drop anonymous requests. Following are some of the most used authentication strategies:
The certificate authority helps to create X509 certificates, which help validate client certificates.
The API server uses a static file to read the bearer tokens. The token file is a comma-separated file consisting of
Kubernetes also supports basic authentication. The authentication credentials are stored in a CSV file as
Service account tokens
Service accounts are created by the
kube-apiserverand are associated with the pods. It verifies signed bearer tokens.
Kubernetes makes a call to a REST API outside the cluster to determine the user’s identity.
Learn more about Kubernetes authentication.
Once the authentication modules identify the origin of the request, active authorization modules evaluate the attributes of the request against the authorization policies of the user to allow or deny the request. Each request passes through the authorization module sequentially and if any module provides a decision to allow or deny, it is automatically accepted or denied. Following are some of the authorization strategies that are frequently used:
Authorization modules parse a set of attributes in a request to determine whether the request should be parsed, allowed, or denied.
Node authorization mode grants permissions to kubelets to access services, endpoints, nodes, pods, secrets, and persistent volumes for a node.
Attribute-based access control (ABAC)
With ABAC, requests are allowed by validating policies against the attributes of the request.
Role-based access control (RBAC)
With RBAC, access to resources is regulated using the roles assigned to individual users.
Similar to the webhook mode for authentication, the webhook mode for authorization uses a remote API server to check user permissions.
Learn more about Kubernetes authorization.
Admission controllers are modules that intercept requests to the API server after the request is authenticated and authorized. The controllers validate and mutate the request before modifying the state of the objects in the cluster. A controller can be both mutating and validating. If any of the controllers reject the request, the request is dropped immediately, and an error is returned to the user so that the request will not be processed. You can enable the admission controllers by using the
--enable-admission-plugins flag. Important admission controllers include:
Learn more about Kubernetes admission controllers.
Securing your container images
You should schedule scans of your container images at regular intervals. Container image scanning tools, such as Portieris and Grafeas, inspect the packages included in an image and help report on any known vulnerabilities included in those packages. When you identify that a container image includes a package with a vulnerability, you should update the container so it uses a fixed version of the package.
A best practice is to not SSH into your running containers. If you factor in the self-healing nature of Kubernetes, which ensures that a failed container will be replaced with a new one, and autoscaling, which can create and destroy containers automatically, it’s not possible to manually keep up with the patching process.
CI/CD best practices
Image scans can be integrated into your continuous integration and continuous delivery (CI/CD) pipeline. Follow some of these best practices:
- A failed scan can result in a failed build.
- A failed scan before deployment can prevent the image from being deployed.
- A failed scan on an image that is already in production can result in an alert so that operators can take remedial action.
More about RBAC
Role-based access control (RBAC) is a security approach to grant specific resources access to users. Following are the broad steps for RBAC:
- Create a client certificate.
- Create a user.
- Grant access to the user.
- Create a
- Create a
RoleBinding, where the
Roleis bound to a subject (or user, in this case).
- Create a
- Test the access.
RoleBinding are scoped to a namespace. If you want to assign the
Role to more than a namespace, then use
ClusterRoleBinding. Following are a few commands that can be referred to for RBAC.
Create a client certificate
Generate a key by using OpenSSL:
openssl genrsa -out <user.key> 2048
Generate a certificate signing request (CSR):
openssl req -new -key <user.key> -out <user.csr> -subj <subject>
Generate the certificate:
openssl x509 -req -in <user.csr> -CA <ca.crt> -CAkey <ca.key> -CAcreateserial -out <user.crt> -days <number of days>
Create a user
Set a user entry in
kubectl config set-credentials <user> --client-certificate=<user.crt> --client-key=<user.key> kubectl config set-context user-context --cluster=<cluster name> --user=user kubectl config view kubectl config use-context <user context>
Grant access to the user
RoleBinding YAML file to assign the action of
kubectl apply -f role.yaml kubectl apply -f role-binding.yaml
Basically, the command
kubectl get pods should fetch the results.
Test the access
Switch the context to user context:
kubectl config use-context <user context>
This should produce output:
kubectl get pods
Note: The aforementioned commands are just for your reference.
This post described some of the important security components for Kubernetes that you should always consider. You should prioritize security while modernizing applications. Learn more about Kubernetes security concepts by watching the Securing multi-tenant Kubernetes with RBAC, IAM, NetworkPolicy, and PSP video session.