Kubernetes security: Preventing secrets exfiltration (CVE-2021-25742)
Kubernetes security is especially important because the CNCF Security tag team performs audits on various CNCF projects, and Kubernetes consistently tops the list in terms of usage as well as vulnerabilities. That’s not to say that Kubernetes is insecure, but it is complex and popular and presents a large opportunity for security mistakes.
The CNCF Security team recently disclosed the presence of a high impact vulnerability in the Kubernetes NGINX Ingress Controller (CVE-2021-25742) which can allow inappropriate access to secrets across all namespaces. This blog post discusses how policy as code can be used to detect many misconfigurations before deployment, using that vulnerability as an example.
Accurics by Tenable has already added policies which identify this vulnerability. If you want to know whether you are vulnerable to this problem, simply sign up for the Accurics platform or leverage the Terrascan open source project to scan your Kubernetes projects. More complete instructions for scanning with Terrascan follow the description of the vulnerability and mitigation.
What is CVE-2021-25742?
|Affected versions of ingress-nginx:||V1.0.0, <=V0.49|
|Impact:||Exfiltration of secrets across all namespaces|
|CVSS Score:||7.6 HIGH (3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L)|
- Your deployment uses a vulnerable version of Ingress-Nginx controller, with a configuration that exposes the vulnerability:
- Snippet annotations are enabled by setting
'true'in the Ingress-Nginx ConfigMap
- And the Ingress-Nginx controller’s ServiceAccount token is attached to a ClusterRole which includes
listpermission on the cluster wide resource
*-snippetannotations with arbitrary code referencing
apiVersion: v1 kind: ConfigMap metadata: labels: helm.sh/chart: ingress-nginx-4.0.6 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.0.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: controller name: ingress-nginx-controller namespace: ingress-nginx data: allow-snippet-annotations: 'true' ---- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: cafe-ingress-with-snippets annotations: nginx.org/*-snippets: | <arbitrary-code-to-access-service-account-token/secrets>
'true'. This compromises Kubernetes security by eventually allowing privileged users to run arbitrary code in Ingress resources through
*-snippetannotations. This can be leveraged to access the controller’s service account token, or to directly access Kubernetes secrets.
Securing Kubernetes against CVE-2021-25742
- For controllers created through default YAML manifests:
kubectl edit configmap -n ingress-nginx ingress-nginx-controller
- (In the editor) Set
- For controllers created using Helm:
helm install [RELEASE_NAME] --set controller.allowSnippetAnnotations=false ingress-nginx/ingress-nginx
How Terrascan can Improve Kubernetes Security
As mentioned earlier, Terrascan and the Accurics platform include policies to identify whether you are exposed to CVE-2021-25742. They are flexible tools and there are actually a few different ways to detect and respond to the presence of this vulnerability in Kubernetes workflows.
Terrascan policies for CVE-2021-25742
allow-snippet-annotations. Rather than force users to customize the policy themselves in the event they need to leave that enabled, we provide a two-part policy that looks for the use of vulnerable versions and for potentially exploitable Ingress configurations.
|AC_K8S_0050||This policy identifies a violation if the version of the NGINX Ingress Controller is <=0.49 or == 1.0.0 and its ConfigMap has
|AC_K8S_0051||This policy identifies a violation if the version of the NGINX Ingress Controller is <=0.49 or == 1.0.0 and an Ingress object is created which includes
Enforcing Kubernetes Security Policy with an Admission Controller
config.tomlin the path
deploy/helm/data/config.tomlwith an appropriate configuration to identify the violations discussed in this post. An example Toml configuration:
[severity] level = "high" [rules] scan-rules = [ "AC_K8S_0050", “AC_K8S_0051” ] [k8s-admission-control] denied-categories = [ "Configuration and Vulnerability Analysis" ] denied-severity = "high"
The configuration denies admission of configuration changes that introduce high severity issues from the specified categories (basically meaning they violate the vulnerability discussed in this blog). Full instructions for running Terrascan as an admission controller is available in this blog.
Enforcing Kubernetes Security Policy in Development and GitOps Workflows
Implementing runtime controls is important, but it is also important to find problems during development, before problems are introduced into runtime and when they are easier to fix. As a result, Terrascan offers a few different integrations to simplify use in development workflows, including a universal command line interface. Because we already include policies to identify this vulnerability, you only need to use Terrascan’s latest Rego based policies to statically scan the IaC (YAML/Helm) repositories and detect this issue. Our getting started document provides a good overview.
If you use a GitOps workflow to deploy workloads in your Kubernetes cluster, you can configure ArgoCD with Terrascan as a PreSync hook to scan the remote repository. Instructions for configuring Terrascan as a PreSync hook are available in the documentation here.
In either case, the Terrascan output will look something like this if problems are found:
With the help of Policy as Code tools such as Terrascan, Cloud native misconfigurations leading to exploitable attack paths can be detected early in the life cycle and potential exploits blocked in runtime.