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. 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 shine. With a simple, easy-to-read, and understandable policy, we can completely mitigate the effect of these CVEs without leaving 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. They should also have the tools to build the hand-in-hand Security and 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.
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.
Sorry, the comment form is closed at this time.