The adoption of Kubernetes and container-based platforms increases the need for security to protect cloud-first initiatives. An essential component of the Kubernetes security is authentication. Kubernetes clusters are machines and always need to be validated via machine identities to ensure the integrity and confidentiality of communications.
With increased adoption, heightened risks
The majority (88%) of IT decision makers are exploring Kubernetes and containers, according to 2021 data from New Relic. However, as with any technology, new security concerns are emerging.
A Red Hat survey of Kubernetes adoption and security showed that
- 55% of DevOps teams delayed an application release due to security issues
- 93% of developers experienced at least one Kubernetes security incident in the past year
- 46% say misconfiguration is the top security concern
Zero Trust with cert-manager, Istio and Kubernetes
The main risks facing Kubernetes production environments can be summarized in the bullets below:
- Compromised images. Images should always be scanned before being used to create containers in a Kubernetes cluster - this avoids tampering. To ensure the security of images, organizations should implement strong governance policies that ensure images are securely built and stored in trusted registries.
- Compromised containers or malicious traffic. Containers and pods need to communicate with each other as part of normal operations. However, this communication can be exploited by threat actors. A breached container can affect other containers and pods.
- Lack of visibility. Visibility is critical to ensure Kubernetes clusters are secured. However, it can be challenging to gain and maintain visibility in containerized environments because of the large number of containers, the dynamic and ephemeral nature of these containers and their deployment across multi-cloud environments.
- Misconfigurations or use of insecure defaults. While Kubernetes provides a wide range of controls that can help organizations effectively secure clusters and applications, it does not provide secure configurations out of the box to cover all communications. Misconfiguration of secrets management is another concern. Secrets define how sensitive information, like keys and credentials, is accessed and stored. Many developers use secrets as environment variables or hardcoded within images making them vulnerable to attacks. Secrets should be managed with careful access control to protect them from unauthorized parties.
- Compliance. Achieving compliance in cloud-native environments is a highly challenging endeavor. To achieve compliance, organizations are usually required to implement certain security measures. This often requires enforcing best practices, benchmarks, and industry standards, as well as internal organizational policies.
Authenticate your K8s clusters with machine identities
To address the above challenges, organizations are required to implement a series of policies and controls to secure their clusters. These controls include defining a network policy, pod security policy and managing the Kubernetes secrets. Besides these important controls, organizations must focus their efforts on controlling access to their clusters. The primary access point for a Kubernetes cluster is the Kubernetes API, therefore we need to authenticate and authorize both developers and services accessing the API. Controlling and limiting who can access the cluster and what actions they are allowed to perform is the first line of defense.
TLS all your API traffic
Kubernetes expects that all API communication in the cluster is encrypted by default with TLS. The majority of cluster installation methods allow the necessary certificates to be created and distributed to the cluster components.
API authentication
API authentication covers both humans and clients accessing the API. For the human side of authentication, you must choose strong verification, based on multifactor authentication methods. The concept of least privilege is extremely crucial. Besides humans, you must also authenticate all API clients, even those that are part of the infrastructure like nodes, proxies, the scheduler, and volume plugins. These clients are typically service accounts or use X.509 client certificates, and they are created automatically at cluster startup or are setup as part of the cluster installation. Setting up an effective, flexible and scalable machine identity management program is the cornerstone of validating the authenticity of these machines.
API authorization
Once authenticated, every API call passes an authorization check. Kubernetes ships an integrated Role-Based Access Control (RBAC) component that matches an incoming user or group to a set of permissions bundled into roles. These permissions combine verbs (get, create, delete) with resources (pods, services, nodes) and can be namespace-scoped or cluster-scoped. As with authentication, simple and broad roles may be appropriate for smaller clusters, but as more users interact with the cluster, it may become necessary to separate teams into separate namespaces with more limited roles.
The solution to overcome many of these challenges is to employ a common service for certificates via an API that is integrated with DevOps tooling. Venafi-as-a-Service integrates seamlessly with Kubernetes and Jetstack cert-manager to improve security and availability of your clusters, ensure compliance, and accelerate software development by reducing complexity. Combining the functionality and efficiency of Venafi and cert-manager allows DevOps engineers to extend the functionality of various different CA’s within Kubernetes with just one integration.
Start your free trial today and begin your path to securing your containerized applications and multi-cloud environments.
Cover every cluster with ease and efficiency.
Related posts