A new Kubernetes security audit has identified “a number of concerns” around user and network permissions.
The Cloud Native Computing Foundation (CNCF) contracted the NCC Group to conduct the Kubernetes security audit following the release of version 1.24 in May 2022 and published its findings at the Kubecon conference.
These also include recommendations for enhancing security of the broader architectural design of Kubernetes.
Thirteen of the total 19 issues NCC identified were in the kube-apiserver (crudely, the entry point for the REST commands used to control a Kubernetes cluster); four were across Kubernetes' broader architectural design.
They include one bug (no CVE has been allocated for this issue, which ultimately a configuration one and arguably not an entirely common one) that would let any authenticated user escalate privileges to cluster administrator.
The audit also flagged inadequate logging capabilities, saying that logs of actions on Kubernetes fail to include authentication sources and would not help Blue Teams identify unexpected behaviour, post-compromise.
Somewhat troublingly, despite Kubernetes contributions continuing to grow (it now has over 3,400 committers and numerous significant enterprise sponsors), the Kubernetes security audit also found that a “number of findings from the previous audit performed against Kubernetes version 1.13 [in 2019] remain open or unfixed.”
The Stack analysed 90k software bugs. Here’s what we learned...
(Kubernetes is an open-source system for automating deployment, scaling, and management of containerised applications across multiple hosts. It is overseen by the CNCF, a foundation established by the Linux Foundation and partners in 2015 to maintain what is now a wide and growing range of cloud native distributed tools.)
The CNCF said that the Kubernetes security audit was meant to “paint a broad picture of the security posture of Kubernetes and its source code base. NCC found six medium risk issues, nine low risk; none were critical or high.
Seven, including three medium risk issues, related to access control issues; four related to authentication.
NCC stress-tested the design of Kubernetes around four primary cluster use cases.
1) Deployed for internal or public-facing apps; 2) For CI/CD pipelines (e.g. to perform automated building, testing, and deployment of software; 3) To execute end-users’ code, typically in a sandbox, e.g. to enable data processing capabilities, or to provide a Platform-as-a-Service; 4) For multi-tenant dedicated services including SaaS.
One of NCC Group's biggest gripes was the way Kubernetes handles authorisation, with the security firm flagging that the main user-facing Kubernetes authorization mode, RBAC, does not support "deny" rules.
As NCC puts it, calling for a new "DecisionDeny" rule: "The Kubernetes’ authorization model is structured such that it will sequentially try all configured authorization modes until one returns an explicit DecisionAllow or DecisionDeny , or return an error in the event that they all return DecisionNoOpinion . While this model can be used similarly to Kubernetes’ admission controller model, in which an allowed Boolean is used and for which any failed validation will result in an overall error, in practice, internal authorizers such as Node and RBAC can only return DecisionNoOpinion on failure, not DecisionDeny, preventing them from fully rejecting accesses."
NCC Group also urged the project in the wake of that findingto "consider implementing a mechanism for an authorization mode to subquery other authorization modes" and to "consider embedding authentication metadata to authorization modes, enabling increased or decreased access based on the context of the user."
Other issues flagged include the fact that it is "possible for any holder of a client certificate from the shared Certificate Authority to trivially authenticate to the API server as any user, by using their certificate to authenticate a request using the request header scheme" -- with NCC Group saying that "The Kubernetes API server should reject any configuration where --client-ca-file and --requestheader-client-ca-file are set to the same value, unless --requestheader-allowed-names has been set to specific values." (See page 18 here for technical details.)
You can read the full Kubernetes security audit here.
