5 best practices for Access Control in Kubernetes

Why do we need access control in Kubernetes?

Access control in Kubernetes is essential to enforce security and prevent unauthorized access. It ensures that only authenticated and authorized users or entities can interact with the Kubernetes cluster's resources. Without access control, there is a higher risk of data breaches and malicious activities within the cluster. In Kubernetes, it is crucial to implement it for maintaining the confidentiality, integrity, and availability of containerized applications.

What are the 5 best practices for access control in Kubernetes?

In short, you have to use a third-party authentication for your API server as it is a very important component in Kubernetes cluster and can be easily protected. You have to use and configure Role Based Access Control (RBAC) instead of using IAM roles because it gives a better granularity control for permissions given in your cluster. You also should use validating admission policy, a new Kubernetes feature which enables to control access inside the cluster between resources. Finally, you should follow best practices when configuring service accounts and managed clusters.

I use Third-Party authentication for API server

Our Recommendation: When securing your Kubernetes cluster, it's essential to use third-party authentication for the API Server. Instead of relying solely on Kubernetes native authentication mechanisms, consider integrating with a third-party auth provider (IdP) such as Google or GitHub. This enhances security by adding another layer of authentication before granting access to the Kubernetes API. It prevents administrators from reconfiguring the Kubernetes API to add or remove users.

Risks addressed by the recommendation:

• Reduced Security Controls: Prevent the risk of unauthorized access by requiring a third-party authentication
• Limited Management: Performances impact of the clusters and heavy workload for administrator to manage and edit accesses.

I use RBAC in my cluster instead of IAM and follow best practices

Our Recommendation: Replace Identity and Access Management (IAM) with Kubernetes Role-Based Access Control (RBAC) for fine-grained access control.

RBAC is a method for regulating access to computer or network resources based on user roles. A RBAC Role or ClusterRole contains rules that represent a set of permissions. A role always defines permissions in a particular namespace while a ClusterRole is a namespaceless resource.

Follow best practices such as the principle of least privilege. For example, you should never use the admin role but give a set of permissions to groups that gather users who need the same rights on the resources. Define roles and role bindings that restrict permissions to only what is necessary for each user or service account. Minimize the distribution of privileged tokens by avoiding giving powerful permissions. Finally, make periodic review of the rights given and check if the permissions are adapted. However, you should not change the rights provided to system.

Risks addressed by the recommendation:

• Overprivileged Users: Without RBAC, users and service accounts may have unnecessarily broad permissions, resulting in overprivileged accounts. This means they could perform actions they shouldn't, potentially compromising the security of the cluster.
• Unauthorized Access: Lack of RBAC means there are no controls in place to restrict access. Any authenticated user can perform any action, increasing the risk of unauthorized access to resources and data.

I securely configure my service account

Our Recommendation: Configure and manage service accounts diligently. Avoid using the default service account whenever possible, as it has broad permissions by default. Create specific service accounts for each application or workload, and associate them with appropriate RBAC roles and role bindings.

Risks addressed by the recommendation:

• Privilege Escalation: Without proper configuration, service accounts may have unnecessary permissions, allowing attackers who compromise a pod to escalate their privileges within the cluster, potentially gaining control over other pods or resources.
• Unauthorized Access: If service accounts are not appropriately scoped and configured, pods might have access to resources they shouldn't, leading to unauthorized data access or unauthorized actions within the cluster.

I use validating admission policy

Our Recommendation: Using validating admission policies is a new Kubernetes feature that offers several benefits that enhance security and streamline management. Some of its features are the same as Kyverno which is a policy engine designed for Kubernetes. If you prefer using Kyverno, we wrote an article about best practices using this tool.

It restricts the access to resources and reduce the number of request a resource must handle, reducing the attack surface. It enables to restrict unnecessary communication between some resources. These policies make it simpler to manage configurations and govern the Kubernetes infrastructure, ensuring that resources adhere to predefined rules. It also can automate tasks like applying labels, adding annotations, and setting resource limits, streamlining the work of DevOps teams.

Risks addressed by the recommendation:

• Security Vulnerabilities: Validation policies can enforce security-related configurations, such as requiring the use of specific security contexts, labels, or network policies (go check out the part 2 of this article to get further details). This reduces the chances of leaving security gaps that attackers could exploit.
• Resource Overallocation: By setting limits and constraints (maximum amount of a resource to be used by a container) through validation policies, the risk of resource overallocation is mitigated. This prevents scenarios where one resource consumes an excessive amount of CPU or memory, affecting the performance of other workloads.

I use built-in secure features in managed clusters

Our Recommendation: If you are using a managed Kubernetes service like Google Kubernetes Engine (GKE), Amazon EKS, or Azure Kubernetes Service (AKS), use the built-in features of the cloud provider that strenghten your security. For example, in GCP, use the library SQLConnector to use IAM service accounts to connect to databases. Alternatively, you can also deploy the sidecars Cloud-SQL Proxy in your cluster.

Risks addressed by the recommendation:

• Security Vulnerabilities: Managed clusters often come with security features and configurations designed to protect against common threats. Not utilizing these features can leave clusters vulnerable to attacks.
• Misconfigurations: Failing to leverage built-in security features can lead to misconfigurations that expose sensitive data or resources. Without these features, it's easier to make mistakes in settings that could compromise the cluster's integrity.

Conclusion

By following the best practices presented in this article, you can significantly reduce the risk of broken access control and improve the overall security of your infrastructure.

In the next article, we will address security best practices in policies, pods and nodes configurations.