Guest post originally published on ARMO’s blog by Ben Hirschberg, CTO & Co-founder at ARMO
With each release, Kubernetes introduces new features and enhancements to improve the user experience and address the evolving needs of its users. Today’s release is no exception. This blog post delves into the security enhancements introduced in Kubernetes 1.28, providing insights into their significance and impact.
Enhancements in Kubernetes 1.28
The Kubernetes 1.28 release has introduced several security improvements. Let’s take a closer look at a few of these.
CEL-based admission policies (#3488) and webhook match conditions (#3716) moving to beta
CEL, or Common Expression Language, is a powerful expression language that can be used to evaluate conditions, perform calculations, and manipulate data.
Admission policies are a highly performant way to define and enforce policies in a Kubernetes cluster. Introduced in alpha in 1.26, they present a valuable alternative to external admission controllers. They enable users to define policies using CEL, which are directly enforced by the API server. This can make other admission controller services redundant in simple policy use cases.
Admission webhooks are a powerful tool to intercept and modify requests to the Kubernetes API server. They are key to ensuring the security and consistency of the cluster. However, the conditions to match specific requests have been limited in their complexity.
Both of these enhancements are based on the Common Expression Language (CEL) as an integral part of the admission webhook. CEL allows defining policies and more intricate and expressive matching conditions. It enables fine-grained control over the requests that trigger the webhook. By integrating CEL, Kubernetes can offer enhanced security and flexibility in defining the conditions under which admission policies and webhooks are invoked:
- Complex matching: Instead of just matching based on simple attributes, with CEL, administrators can define conditions; for example, if the request is from namespace X and the resource is labeled Y, then trigger the webhook.
- Improved security: By allowing more specific match conditions, administrators can ensure that only the intended requests are intercepted, reducing potential attack vectors.
- Flexibility: CEL provides a rich expression language, enabling you to define a wide range of conditions, catering to various use cases.
- Performance: CEL provides better performance, by virtue of working from within the API server, rather than the outside.
Kubescape provides users with a pre-made set of admission policies based on its well-known controls, reproduced in CEL.
Reduction of secret-based service account tokens (#2799)
Service account tokens are a foundational element of Kubernetes’ authentication mechanism. These tokens, stored as secrets, allow pods to communicate with the API server. However, as Kubernetes has evolved, the heavy reliance on secret-based tokens has been identified as a potential security and management concern. This enhancement offers users a way to reduce their usage of these tokens.
The primary goal is to strengthen the security posture of Kubernetes clusters by minimizing the potential attack surface associated with these secret-based service account tokens. Additionally, decreasing reliance on these tokens should also lower the management overhead for cluster administrators.
Ensure secret pulled images (#2535)
In Kubernetes, when pulling images, the IfNotPresent policy is often used. This policy checks if the image is already present on the node; if it is, the image is not pulled again. However, this can pose a security risk if the image on the node is outdated or has been tampered with. Ensuring that images are pulled securely, especially when using this policy, is crucial for maintaining the integrity and security of applications running in the cluster.
Consider a scenario where an image is pulled to a node with the IfNotPresent policy. Later, an attacker gains access to the node and manipulates the image. The next time a pod is scheduled to use this image, the tampered image will be used.
The goal of this enhancement is to ensure that images are pulled securely, especially when the IfNotPresent policy is used. This involves checking the integrity of the image on the node and comparing it with the image in the registry. If there’s a mismatch or the image on the node is compromised, the image will be pulled from the registry again. This ensures that only verified and secure images are used in the cluster.
Container image signature handling based on sigstore (CRI Blog)
This enhancement introduces the handling of container image signatures based on sigstore, improving the security of container image management in Kubernetes.
As containerized applications become more prevalent, ensuring the integrity and authenticity of container images is paramount. Image signatures provide a means to verify that the image’s content hasn’t been tampered with and originates from a trusted source.
The improvement is based on validating container image signatures in CRI (container runtime interface) runtimes. Previously, image signatures were validated by an admission controller. This worked well when the node that pulled the container image was the same node that performed the admission. However, if these nodes were different, the admission controller could be bypassed.
The new enhancement to Kubernetes uses the CRI-O runtime to validate image signatures. CRI-O is a lightweight container runtime that is often used in Kubernetes clusters. When pulling an image, CRI-O checks the signature and ensures its validity. If an image has been altered or does not have a required signature, CRI-O will prevent its pull and inform the user. This ensures that only verified and secure images are used in the cluster.
KMS v2 improvements (#3299)
Key Management Service (KMS) is a critical component in Kubernetes that ensures that sensitive data like secrets are encrypted before storing them.
The KMS v2 improvements introduce a new API version that provides performance enhancements, better key rotation mechanisms, and improved observability. This ensures that encryption and decryption processes are more efficient, keys can be rotated seamlessly without causing disruptions, and there is better visibility into the operations of the KMS.
The new improvements in the KMS v2 provider make it more secure and reliable. If a key used for encrypting secrets in Kubernetes is compromised, the system can seamlessly rotate to a new key. Thus, ensuring that the secrets remain secure. Additionally, administrators can gain insights into the performance of their KMS, helping them make informed decisions about scaling or optimizing the service.
This enhancement has been actively discussed and tracked, and it remains in beta for the 1.28 release.
Auth API to Get Self-User Attributes (#3325)
This enhancement provides a mechanism, an Auth API, for users to retrieve their own attributes, ensuring they have the correct permissions and roles within the cluster. This improves user management security in Kubernetes; it is especially useful for administrators and developers to verify user attributes and confirm proper access controls. Our blogs previously discussed this enhancement when it was released in alpha and beta.
Conclusion
As Kubernetes becomes more essential to organizations’ infrastructure, it is critical to make apps running on Kubernetes more secure. This release includes several enhancements that help users proactively address potential security risks.
These enhancements demonstrate the way in which the Kubernetes community approaches building a secure and reliable container orchestration platform by continually iterating on its features and introducing robust security measures.
As clusters grow and develop, these enhancements will undoubtedly play a critical role in ensuring that they remain secure, efficient, and resilient in the face of an ever-evolving threat landscape.