Kubernetes 1.29 will be the last release from the Kubernetes team for 2023. The new release has 49 enhancements, with a multitude of beta and stable ones in addition to a high number of bug fixes.
As Kubernetes security professionals, we explored the release to find the most notable security-centric features and improvements. This blog is tailored for those with a keen eye for security, aiming to break down how these changes will impact and enhance the security posture of Kubernetes clusters.
Understanding the significance of these enhancements requires not only a grasp of what they are but also their implications. Each provides a different puzzle piece, contributing to a broader picture of a more secure, efficient, and reliable Kubernetes.
Read on as we unpack these features, offer insights into why they matter, and reveal how they can be leveraged to secure your Kubernetes environment further.
Kubernetes 1.29 brings a collection of general enhancements that, while not exclusively security-focused, contribute significantly to the security posture of Kubernetes clusters by improving reliability, resource management, and operational efficiency.
Exposing node resource metrics about first-class resources allows for more efficient resource management. Security is enhanced, as it enables operators to detect and prevent resource starvation, which can be a vector for certain types of attacks. By ensuring that clusters operate efficiently and resources are allocated appropriately, operators can avoid scenarios where critical workloads are under-resourced and potentially vulnerable.
Learn more about this enhancement in KEP-727.
The introduction of a sleep action to delay the termination of pods is crucial for debugging and can be beneficial for the graceful shutdown of services. This feature allows administrators to investigate and capture the state of pods before they are terminated, which can be useful for identifying and addressing security issues.
With the new feature, you might add it to your pod specification to delay termination of the pod:
apiVersion: v1 kind: Pod metadata: name: my-debug-pod spec: containers: - name: my-container image: my-image lifecycle: preStop: sleep: duration: "60s" # Delay termination by 60 seconds
Learn more about this enhancement in KEP-3960.
Sidecars are auxiliary containers that add functionality to a primary container. Better handling of the lifecycle events of sidecar containers means that logging, monitoring, and security agents run as sidecars can be more reliably managed; this in turn ensures that these critical services remain operational throughout the lifecycle of the main application, enhancing the reliability of these security services.
Sidecar containers are defined as part of init containers in the pod spec with a specific restart policy of Always:
apiVersion: v1 kind: Pod metadata: name: my-pod spec: initContainers: - name: proxy image: envoy:latest # Unlike other init containers, this init container will be always running: restartPolicy: Always …
In this version the side car containers now deafult to enabled. In addition, you can now terminate sidecars in the reverse order to their startup.
Learn more about this enhancement in KEP-753.
This change aims to deprecate SPDY in favor of WebSockets for Kubernetes API server communications. WebSockets provide a more modern and scalable protocol that can improve the overall reliability and maintainability of Kubernetes communications. This can enhance security by making sure that the communication protocols used by Kubernetes are robust and well-supported.
These general enhancements contribute to a more secure and efficient Kubernetes environment. By improving Kubernetes’ underlying reliability, performance, and operational control, the above features lay the groundwork for a more secure infrastructure platform capable of hosting sensitive and critical workloads.
Learn more about this enhancement in KEP-4006.
With a solid foundation of general enhancements in Kubernetes 1.29, we can now focus on the features explicitly designed to increase the security of the Kubernetes ecosystem. These enhancements address some of the most critical aspects of cloud-native security, such as authentication, authorization, and secure workload management.
Authorization in Kubernetes has traditionally been managed through RBAC (role-based access control), which can become unwieldy as the number of roles and policies grows. This change proposes a more structured configuration model, which enhances manageability and traceability. With a clearer authorization configuration, security audits are simplified, making it easier to enforce and verify access policies.
With the following configuration, it is possible to protect CRDs in the kube-system namespace from deletion:
apiVersion: apiserver.config.k8s.io/v1alpha1 kind: AuthorizationConfiguration authorizers: - type: Webhook name: crd-protector webhook: ... failurePolicy: Deny ... matchConditions: - expression: has(request.resourceAttributes) - expression: request.resourceAttributes.namespace == 'kube-system' - expression: request.resourceAttributes.verb in ['update', 'delete','deletecollection'] - type: Node - type: RBAC
Learn more about this enhancement in KEP-3221.
Service account tokens represent a significant aspect of Kubernetes security and are used to authenticate workloads within the cluster. Kubernetes 1.29 enhances the security of these tokens by binding them to specific pod instances, preventing their misuse if exfiltrated. This ties the use of a service account token to the lifecycle of the pod, reducing the window of opportunity for an attacker to exploit a stolen token.
Learn more about this enhancement in KEP-4193.
In addition to “Bound Service Account Token Improvements” enhancement and narrowing the scope of service account tokens, this improvement seeks to reduce the reliance on long-lived secret-based service account tokens. By limiting the use of these tokens, the potential attack surface is significantly diminished.
This move aligns with the broader industry trend of short-lived, just-in-time credentials that minimize the chances of token leakage leading to unauthorized access.
Learn more about this enhancement in KEP-2799.
Container images often contain sensitive components, making the security of image pull operations critical. The new alpha feature makes sure that images are always pulled using Kubernetes secrets of the Pod using them. This is important when Kubelet pulls an image for one Pod and another Pod is pointing to the same image. Up until now, the second Pod’s image request did not need authentication since it still used the first one’s credentials. This could lead to unauthorized access. By securing the image pull process, this enhancement prevents attackers from intercepting or tampering with container images, which is vital for maintaining the integrity of workloads.
Learn more about this enhancement in KEP-2535.
Namespaces in Linux act as a form of virtualization, providing isolation between various aspects of the kernel. This alpha enhancement supports user namespaces and improves Kubernetes security by allowing for more granular control over containerized processes. This means better isolation and separation of workloads, which will, in turn, lower the risk of privilege escalation attacks.You can enable a user namespace for a pod by setting the hostUsers
field:
apiVersion: v1 kind: Pod metadata: name: my-pod spec: hostUsers: false containers: - name: shell command: ["sleep", "infinity"] image: debian
Learn more about this enhancement in KEP-127.
Similar to the authorization counterpart, Kubernetes 1.29 provides another alpha feature for structured configuration for authentication mechanisms. This enhancement offers users a more maintainable and secure approach to managing authentication, allowing administrators to implement complex authentication schemes more efficiently and with less room for error.
With the new enhancement, it is now possible to configure multiple OIDC providers, clients, and validation rules:
apiVersion: apiserver.config.k8s.io/v1alpha1 kind: AuthenticationConfiguration jwt: - issuer: claimValidationRules: ... - expression: 'claims.exp - claims.nbf <= 86400' message: total token lifetime must not exceed 24 hours claimMappings: username: expression: 'claims.username + ":external-user"' groups: expression: 'claims.roles.split(",")' … userInfoValidationRules: - rule: "!userInfo.username.startsWith('system:')" message: username cannot used reserved system: prefix - rule: "userInfo.groups.all(group, !group.startsWith('system:'))" message: groups cannot used reserved system: prefix
Learn more about this enhancement in KEP-3331.
The Kubernetes Key Management Service (KMS) is critical for the secure management and encryption of secrets. With the new release of Kubernetes, this has become a stable feature that focuses on improving the KMS plugin framework, which is paramount for secure secret management. These improvements ensure that Kubernetes secrets remain a robust and secure method for storing sensitive information.
Learn more about this enhancement in KEP-3299.
The Kubernetes 1.29 release represents the community’s commitment to ongoing improvement, with various updates that enhance stability and efficiency. From a security point of view, we’ve highlighted how the release contributes to the hardening of Kubernetes, addressing emerging threats in the landscape.
Our exploration underscores the evolutionary nature of Kubernetes—each release is a step forward in reliability and performance for the diverse needs of its global user base.For a comprehensive overview of v1.29’s new features and their impact, visit the Kubernetes project’s official blog and GitHub repository.
Experience effective, end-to-end, from dev to production, Kubernetes protection:
Manage Kubernetes role-based-access control (RBAC) visually
Eliminate misconfigurations and vulnerabilities from your CICD pipeline – from YAML to cluster
Full Kubernetes security compliance in a single dashboard
The post Kubernetes 1.29: The Security Perspective appeared first on ARMO.
*** This is a Security Bloggers Network syndicated blog from ARMO authored by Ben Hirschberg. Read the original post at: https://www.armosec.io/blog/kubernetes-1-29-security/