Mitigating the Latest Kubernetes NGINX Ingress Controller CVEs

Mitigating the Latest Kubernetes NGINX Ingress Controller CVEs

Securing Nginx with Kyverno

Recently, a few new vulnerabilities for Kubernetes Nginx Ingress controllers have made their way across industry channels, showcasing how much of a challenge securely configuring Kubernetes can be.

The vulnerabilities, tracked as CVE-2023-5043, CVE-2023-5044 and CVE-2022-4886, were disclosed on October 27, and are listed as currently awaiting triage. It’s unclear if any of the flaws have been exploited.

The vulnerabilities themselves abuse improper input validations, thus granting the ability to inject arbitrary code into the stream, but worse, an attacker can actually steal all secrets stored on a cluster without any proper security compliance or governance mechanisms in place.

This is where the power of Kyverno, created here at Nirmata and donated to the CNCF, begins to really shine. With a simple, easy to read and understand policy, we can completely mitigate the effect of these CVEs without ever having to leave our “everything-as-code” cloud-native loop.

By creating a simple policy declaration and applying it to a cluster running Kyverno as an admission controller, we can effectively mitigate and remediate any resources that could be affected by preventing the offending annotations from being used:


apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-annotations
  annotations:
    policies.kyverno.io/title: Restrict Nginx Annotations
    policies.kyverno.io/description: >-
      Prevent the nginx-related CVE-2023-5043 and CVE-2023-5044 by blocking configuration-snippet and permanent-redirect
    pod-policies.kyverno.io/autogen-controllers: none
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: block-nginx-annotations
    match:
      any:
      - resources:
          kinds:
          - Ingress
    validate:
      message: Cannot use nginx.ingress.kubernetes.io annotations for configuration-snippet or permanent-redirect, remediating CVE-2023-5043 and CVE-2023-5044
      pattern:
        metadata:
          =(annotations):
            X(nginx.ingress.kubernetes.io/configuration-snippet): "*" # CVE-2023-5043
            X(nginx.ingress.kubernetes.io/permanent-redirect): "*" # CVE-2023-5044

In order to mitigate CVE-2022-4886, we would have to look at the problem more strategically and evaluate the pathTypes we are currently using and instead create a whitelist. A sample way of achieving this is below:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-ingress-path-type
spec:
  validationFailureAction: Enforce
  rules:
    - name: block-specific-path-types
      match:
        resources:
          kinds:
            - Ingress
      validate:
        message: "pathType '/{{request.object.spec.rules[].http.paths[].pathType}}' is not allowed in this namespace"
        deny:
          conditions:
            all:
              - key: "{{request.object.spec.rules[].http.paths[].pathType | [] }}"
                operator: AnyNotIn
                value: [ImplementationSpecific]

Ultimately, any and all institutions should assume zero trust and work towards having the correct tools to allow them to rapidly mitigate emerging threats as well as have the tools in order to build the hand in hand Security & Governance that operating Kubernetes at scale demands.

Kyverno offers many other features to help automate security and compliance concerns. You can learn more about Kyverno at: https://kyverno.io.  

Kyverno offers many other features to help automate security and compliance concerns. You can learn more about Kyverno at: https://kyverno.io.  

For an even faster results and increased peace of mind, though we recommend you take a look at the Nirmata Policy Manager trial which will allow you to simply drag and drop a policy such as the above and mitigate and bring into compliance all of your infrastructure from a single pane of glass. 

 

Whats new in Kyverno Release 1.11!
Image Verification with Kyverno, Notation, and Azure AD Workload Identity on AKS
No Comments

Sorry, the comment form is closed at this time.