Basics of Kubernetes security – IBM Developer

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:

• Authentication
• Authorization
• 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

Authentication modules

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:

• Client certificates
  The certificate authority helps to create X509 certificates, which help validate client certificates.

• Static tokens
  The API server uses a static file to read the bearer tokens. The token file is a comma-separated file consisting of secret, user, uid, group1, and group2.

• Basic authentication
  Kubernetes also supports basic authentication. The authentication credentials are stored in a CSV file as password, user, uid, group1, and group2.

• Service account tokens
  Service accounts are created by the kube-apiserver and are associated with the pods. It verifies signed bearer tokens.

• Webhook tokens
  Kubernetes makes a call to a REST API outside the cluster to determine the user’s identity.

Learn more about Kubernetes authentication.

Authorization modules

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:

• Request attributes
  Authorization modules parse a set of attributes in a request to determine whether the request should be parsed, allowed, or denied.

• Nodes
  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.

• Webhooks
  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

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:

• AlwaysAdmit
• AlwaysPullImages
• EventRateLimit
• LimitRanger
• NodeRestriction
• PersistentVolumeClaimResize
• PodSecurityPolicy
• SecurityContextDeny
• ServiceAccount

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:

1. Create a client certificate.
2. Create a user.
3. Grant access to the user.
   • Create a Role.
   • Create a RoleBinding, where the Role is bound to a subject (or user, in this case).
4. Test the access.

Role and RoleBinding are scoped to a namespace. If you want to assign the Role to more than a namespace, then use ClusterRole and ClusterRoleBinding. Following are a few commands that can be referred to for RBAC.

Create a client certificate

1. Generate a key by using OpenSSL:

   openssl genrsa -out <user.key> 2048
   

   Show more

2. Generate a certificate signing request (CSR):

   openssl req -new -key <user.key> -out <user.csr> -subj <subject>
   

   Show more

3. Generate the certificate:

   openssl x509 -req -in <user.csr> -CA <ca.crt> -CAkey <ca.key> -CAcreateserial -out <user.crt> -days <number of days>
   

   Show more

Create a user

Set a user entry in kubeconfig:

  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

Create a Role and RoleBinding YAML file to assign the action of read-pods to <user>:

  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:

Note: The aforementioned commands are just for your reference.

Summary

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.