Intro
The newest release of Kubernetes, v1.28, is now available, bringing with it significant updates that enhance its default stability and security. At first glance, it might not be immediately clear how many of the updates, like enhancements in memory storage allocation, impact security. Other updates, such as the advancement of an admission policy to Beta, have more obvious security implications. In this blog, we will review all the security implications of v1.28, which are critical to keep in mind as you contemplate your upgrade strategy.
The "Auth API to get self-user attributes" has graduated to stable
The "Auth API to get self-user attributes" has graduated to stable. This addition provides an API endpoint allowing users to fetch their own attributes, notably group memberships. It used to be very hard to verify, when running kubectl commands, which user you were operating under. These feature improvements make it much easier to answer that question.
Through this feature, users can retrieve a variety of attributes from the API server, including but not limited to:
- Username
- Group memberships
- Extra attributes (could be any additional data provided by the authentication method in use, such as provider-specific metadata)
The functionality checks who you are, your attributes (groups, extra) and can be invoked with kubectl auth whoami . The output looks like this:
This is especially useful in clusters with dynamic authentication mechanisms like token webhooks, auth proxies, or OIDC providers.
Understand your user permissions with KSOC
To go a few steps further in understanding your user permissions, KSOC provides multiple angles to explore your RBAC posture.
You can view aggregated permissions for users:
You can drill into any one set of permissions to clearly understand where you have issues, diving into detail where required:
Or you can start from the beginning and search all of your parameters, filtering as you like:
Improvements in CustomResourceDefinition validation rules
CustomResourceDefinition (CRD) validation rules graduated to Beta in v1.25 of Kubernetes. In this release, there are some improvements to the capability. Validation rules for CRDs mean that CRD creation can be approved or denied based on validation rules instead of complex webhooks. On the surface,this might not appear to have any security ramifications, but looking at examples of how one might use the rules, there are clear security ramifications in multiple use-cases.
Security implications of the CRD validation rules
Below are the examples listed in the Kubernetes documentation; on the very bottom there is one listed as very last one, where a rule can validate that the primary property appears only once in the listMap. One could imagine a scenario where an attacker finds a way to hide its own CRD by naming it the same as a legitimate one. This rule - and many of the other example rules listed - would be important in teasing out any malicious (or accidental) attempts at duplication.
Which do you need, Validation Rules or Webhooks?
When deciding between validation rules and webhooks in systems like Kubernetes, several distinctions stand out:
Simplicity: Validation rules, being built directly into systems, offer straightforward implementation and reduced maintenance overhead. On the contrary, webhooks, as external entities, demand continuous monitoring, potential service upkeep, and code management.
Performance: With validation rules being intrinsic, they naturally provide quicker responses, avoiding the potential lag inherent in webhooks, which necessitate external HTTP calls.
Scalability: While validation rules effortlessly scale as an integral part of the system they're in, webhooks introduce an added layer of complexity, necessitating independent scalability solutions.
Flexibility: Validation rules typically come with predefined and limited capabilities. In contrast, webhooks shine in this area, offering the latitude for custom logic, bespoke functionalities, and even third-party system integrations.
Reliability: The core system integration of validation rules grants them higher robustness, whereas webhooks, being external, introduce another possible point of failure in the system.
Feedback: Standardized, easy-to-decipher error messages are the hallmark of validation rules. Meanwhile, webhooks, with their capacity for tailored responses, can deliver custom messages, but these can sometimes skew towards inconsistency or lack of clarity.
In summation, validation rules stand out for their efficiency, performance, and robustness, making them a preferred choice for straightforward validation tasks. Webhooks, although posing potential challenges in performance and reliability, offer unparalleled flexibility, making them suitable for intricate, custom validation needs.
Validating Admission Policy (Beta) vs. Validating Admission Webhooks
The Validating Admission Policy has been moved into Beta and is an enhancement to the existing ValidatingWebhookConfiguration. It introduces an additional field that allows users to narrow down Admission Control actions to a specific subset of resources. By ensuring the Admission Control fires only for relevant resources, it improves the response times from the Kubernetes Control Plane when encountering non-matching resources.
With validating admission policy, you can get more simple and performant admission control policy checks, which has the potential to loosen the current industry reliance on having a third-party like OPA or Kyverno in your clusters for admission control policies. The addition of Common Expression Language (CEL) in this part of the release may also have better developer ergonomics for some.
Here is the Validating Admission Policy example from the Kubernetes documentation:
Match conditions for Admission Webhooks; moved into Beta and enabled by default
Admission webhooks in Kubernetes provide custom validation and mutation of API requests. By introducing match conditions into beta, users can specify when Kubernetes should invoke these webhooks, narrowing the scope and ensuring that the webhooks are called only for pertinent requests. This enhancement reduces unnecessary external calls, minimizing the attack surface and potential points of failure.
Security implications of match conditions for admission webhooks
By only triggering the webhooks when truly needed, it reduces the risk of malicious or erroneous interference. Additionally, by cutting down on needless calls, it enhances the performance and stability of the cluster. In essence, it’s a more precise, efficient, and secure approach to admission control.
How KSOC Helps with admission control
Practically speaking, many teams find it overwhelming to enforce admission control policy because of its capability to cause breaking changes in production (as is true with any control that can prevent a workload from running). As such, KSOC offers a ‘would block’ mode to provide a medium between ‘not enforce’ and ‘enforce’ for admission control policies. With ‘would block,’ your engineering team can clearly see which admission control policies are being triggered, without enforcing a block mechanism.
Swap Support for nodes is moved to Beta
Kubernetes has had swap capability in alpha since v1.22. Swap is using space on a host disk once the amount of physical RAM memory is full. Support for this capability has now moved to Beta. There are two ways swap can be applied, either in a ‘limited’ or ‘unlimited’ way. If you choose the limited option, be advised that your Cgroup version (v1 or v2) will determine your true options for limiting how much space to use from the host disk.
Security implications of swap support
It is important to put guardrails into place using the options available, otherwise attackers could exploit the swap function, quickly filling the node's memory. This would force the system to heavily rely on the slower disk-based swap, causing notable performance issues and potentially denying service to genuine users. The unlimited option is the one that doesn’t provide any guardrails, it is strongly recommended to be wary when choosing this option, or simply to choose the limited option to ensure you are not open to a disk-style DoS attack.
Mixed Version Proxy (Alpha)
This capability creates a transparent mapping of API servers on a certain Kubernetes version to resources with the same version, which is helpful during the inevitable upgrades and downgrades involved in running Kubernetes. The improved availability allowed with this feature during upgrades/downgrades allow you to do a partial deploy by putting in multiple control plane components. If you have a complicated cluster where it is hard to do upgrades, this can allow you to upgrade easier by doing it step by step upgrading one controller at a time.
Security implications of Mixed Version Proxy
Upgrading is a critical process to securing your overall Kubernetes environment, so any features (even though they maybe in alpha and require some room for error) that make this process easier will contribute to your overall security.
Support for CDI injection into containers (alpha)
The Container Device Interface (CDI) offers a standardized method for vendors to utilize plugins within Kubernetes. This avoids the need for distinct plugins for every runtime and offers clearer visibility at the Kubernetes level. With the introduction of the CDIDevices field in CRI via Kubernetes v1.27, security vendors can deploy more easily in runtime and it's simpler for observability tools. Historically, integrating additional devices into Kubernetes has been challenging, but CDIs streamline and secure this process.
Security implications of support for CDI injection
Observability and security tools are obviously critical for securing a Kubernetes environment. In the past, trying to add additional devices to Kubernetes runtime has been a huge pain point. It is not an easy process. CDIs simplify the process making it much more secure and easier to manage, which in turn supports the observability and security goals of the plugins themselves.
CDIs offer better security and efficiency
Enhanced Isolation: CDI devices are designed with specific configurations and access controls. Integration through a standardized API ensures that only authorized containers access these resources.
Uniformity: This standardization eases the management of complex devices across different container runtimes, fostering a secure environment.
Standardization: CDI ensures compatibility across different container runtimes and orchestrators, making device description and injection consistent.
Granular Control: CDI device injection enables administrators to determine which devices containers can access, bolstering security.
Device Plugin Flexibility: CDI's design eliminates the need for workarounds like container annotations for device information sharing.
CRI Runtimes Compatibility: CRI structures and runtimes' acceptance of CDI device requests facilitate seamless integration.
Container Runtime Enhancements: CRI runtimes, such as Containerd and Cri-o, now support CDI devices, ensuring comprehensive device injection solutions.
Conclusion
Kubernetes v1.28 demonstrates a dedication to overall improvement and introduction of features with broad security ramifications, from efforts to ease the update process itself, to efforts that improve the explicit security capabilities with admission controllers and better visibility of user permissions. Continuing to build this baseline will be critical as the adoption of Kubernetes increases, attacks targeting Kubernetes become more frequent and Kubernetes CVEs occur regularly.
To discuss further how any of these changes might impact your Kubernetes migration efforts, or to triage your Kubernetes risk and detect Kubernetes-targeted attacks in the time it takes for your next coffee break, join us for a demo today.
