How to Secure Kubernetes Clusters in 7 Steps
With the increased adoption of containers and container orchestrators by small and medium businesses, the need to protect any critical or sensitive infrastructure that runs container workloads has also increased.
As Kubernetes is the most popular container and container orchestration tool, let’s discuss the security best practices that organizations should adopt to secure their Kubernetes clusters.
1. Upgrade Kubernetes to the latest version
The most basic and overlooked security best practice is keeping Kubernetes environments up to date. Take advantage of new updates and releases of security features and bug fixes. Also, use the latest stable release in the test environment before deploying to the production cluster.
2. Secure Kubernetes API Server Authentication
Kubernetes APIs serve as the main access point for a Kubernetes cluster. Administrators or service accounts can access APIs through the command line utility kubectlREST API calls or other client SDKs.
The Kubernetes API server, also known as kube-apiserver, hosts the APIs and is the heart of a Kubernetes cluster. The server grants access and ensures that a cluster is operational.
As a best practice, all API calls in the cluster should use Transport Layer Security, which is encrypted. Adopt an API authentication mechanism for API servers in accordance with access requirements.
Common authentication methods include simple certificates or a bearer token. Large-scale enterprise-level clusters should integrate with third-party OpenID Connect providers or Lightweight Directory Access Protocol servers to segregate users into specific groups and control access. Refer to Official Kubernetes Documentation for an overview of how to authenticate users and authentication strategies.
3. Enable role-based access control authorization
Role-Based Access Control (RBAC) is an access control mechanism that allows users and applications to perform specific actions based on the least-privilege model and apply only required permissions. It may seem cumbersome – it requires additional setup work – but it’s impossible to secure large-scale Kubernetes clusters that run production workloads without implementing RBAC policies.
Here are some Kubernetes RBAC best practices for administrators to follow:
- To enforce RBAC as a standard configuration for cluster security, enable RBAC in an API server by passing the –authorization-mode=RBAC setting.
- Use dedicated service accounts per application and avoid using the default service accounts created by Kubernetes. Dedicated service accounts allow administrators to enforce RBAC for each application and provide better controls for granular access granted to each application resource.
- Reduce optional API server flags to reduce the attack surface on the API server. Each flag activates some aspect of cluster management, which can expose the API server. Minimize using these optional flags:
- – insecure binding address; and
- – insecure port.
- For an RBAC system to be effective, apply least privilege. When cluster administrators follow the principle of least privilege and assign only required permissions to a user or application, everyone can do their job. Don’t grant any extra privileges and avoid generic verbs [“*”] or widespread access.
- Continuously update and adjust RBAC policies to prevent them from becoming obsolete. Remove any permissions that are no longer needed. It can be tedious, but it’s worth it for securing production workloads.
4. Control access to the kubelet
The kubelet is an agent that runs on each node in the cluster. It interacts with users through a set of APIs that control pods running on nodes and perform specific operations. Unauthorized access to the kubelet allows attackers to access APIs and can compromise the security of nodes or clusters.
Take the following steps to reduce this attack surface and prevent unauthorized API access through the kubelet:
- Disable anonymous access by setting the –anonymous-auth flag to false before starting the kubelet: –anonymous-auth=false.
- Start the kube-apiserver –kubelet-client-certificate and –kubelet-client-key flags. This ensures that the API server authenticates against the kubelet and stops anonymous calls.
- The kubelet provides a read-only API, which administrators can access without authentication. This could expose potentially sensitive cluster information. Administrators should therefore close read-only ports using the following command: –read-only-port=0.
5. Strengthen node security
To harden the security of the nodes on which the pods run, start by:
Configuration standards and benchmarks. Properly configure the host according to security recommendations. Validate clusters against Internet Security Center benchmarks related to specific Kubernetes versions.
Minimization of administrator access. Reduce the attack surface by reducing administrative access on Kubernetes nodes.
Node isolation and restrictions. Run specific pods on certain nodes or groups of nodes. This ensures that pods run on nodes with specific isolation and security configurations.
To control which nodes a Pod can access, add tags to Node objects to allow Pods to target specific nodes:
kubectl label nodes
Once the node label is applied, add a nodeSelector to pod deployments so that the pod deploys to the selected node, as in the following YAML file:
- name: nginx-staging
6. Configure namespaces and network policies
Namespaces isolate sensitive workloads from non-sensitive workloads. Although managing multiple namespaces can be complex, it makes it easier to implement security controls such as network policies on sensitive workloads to control traffic flow to and from pods.
7. Enable audit logging
Enable audit logs for Kubernetes clusters and monitor them for malicious activity and suspicious API calls. Kubernetes can keep granular records of actions performed in the cluster. Audit logs detect potential security issues in near real time. For example, an attacker trying to brute force a password can generate logs related to authentication and authorization. If they are repetitive, it could be a security issue.
Audit logs are disabled by default; to enable them, use Kubernetes audit policy, which allows administrators to set one of four levels of auditing:
- Nothing. Do not log events that match this rule.
- Metadata. Log request metadata, such as requesting user, timestamp, resource, and verb.
- Request. Save the event metadata and the request body, but not the response body. This does not apply to requests other than resources.
- Response request. Save event metadata, requests, and response bodies. This does not apply to requests other than resources.
Follow the steps below to enable audit logs on Kubernetes clusters:
- Start by SSHing into the master node.
- Create an audit log policy file using the following YAML file and save it as yaml:
- level: Metadata
- group: ""
resources: ["pods/log", "pods/status"]
- level: RequestResponse
- group: ""
- Create a new directory on the master node to store audit logs, for example, at /kube/auditlogs/.
- To configure the kube-apiserver to load audit policy, edit the manifest file at the location /etc/kubernetes/manifests/kube-apiserver.yamland add the -audit-policy-file flag to the YAML policy created in step 2. Or set -audit-log-path to direct audit logs to a specific file.
- Save and exit the file.