Rapid Mitigation of CVE-2023-2878 with Kyverno and Nirmata Control Hub
Updated Boris Kurktchiev
CVE-2023-2878 is a medium-severity flaw in the Kubernetes secrets-store-csi-driver. Versions before v1.3.3 write service account tokens to the driver logs when TokenRequests is set on the CSIDriver object and the driver runs at log level 2 or higher. Upgrade to v1.3.3. Until then, a Kyverno policy can hold the log level at 0 or 1.
CVE-2023-2878 at a glance
| Field | Detail |
|---|---|
| CVE | CVE-2023-2878 (NVD, Kubernetes advisory) |
| Component | secrets-store-csi-driver (kubernetes-sigs) |
| Severity | Medium: CVSS 3.1 6.5 from Kubernetes (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N), 5.5 from NVD |
| Affected | Versions before v1.3.3, when TokenRequests is configured and the driver runs at -v=2 or higher |
| Fixed | v1.3.3 |
| Mitigation in this post | Upgrade; until then, a Kyverno policy that keeps the driver at log level 0 or 1, plus a policy that flags a CSIDriver with tokenRequests |
What is CVE-2023-2878?
This vulnerability (CVE-2023-2878) in the secrets-store-csi-driver component of Kubernetes poses a significant security risk. If exploited, this vulnerability could result in the disclosure of sensitive service account tokens. Service account tokens function as authentication credentials, allowing applications operating within a Kubernetes cluster to interact securely with other services and resources. Should these tokens fall into unauthorized hands, attackers could gain illicit access to confidential information, impersonate legitimate users, or disrupt critical services.
The impact of this vulnerability is substantial, potentially affecting any Kubernetes cluster utilizing specific logging configurations. Although applying patches to the secrets-store-csi-driver is the recommended long-term solution, patching and updating Kubernetes components can be time-consuming. In such circumstances, Kyverno policy enforcement is a valuable tool for prompt risk mitigation.
How does Kyverno policy enforcement help with CVE-2023-2878?
Kyverno is an open-source policy engine designed to enforce policies and ensure compliance in Kubernetes environments. With Kyverno, organizations can swiftly implement policies restricting access to sensitive resources, including service account tokens. These policies can be configured to prevent any attempts to log or expose secrets, thereby minimizing the risk of unauthorized access.
Here is how Nirmata Enterprise for Kyverno policy enforcement can contribute to mitigating the risks associated with CVE-2023-2878:
- Rapid Policy Implementation: Nirmata Enterprise for Kyverno facilitates the swift creation and deployment of policies, enabling organizations to respond promptly to security vulnerabilities like CVE-2023-2878.
- Fine-Grained Access Control: Nirmata Enterprise for Kyverno policies can be configured to enforce fine-grained access control, ensuring that only authorized entities can access sensitive resources.
- Real-Time Monitoring and Enforcement: Nirmata Enterprise for Kyverno continuously monitors Kubernetes resources to assess compliance with defined policies. Any deviations from the guidelines or suspicious activities are identified and addressed in real-time.
- Auditability and Transparency: Nirmata Enterprise for Kyverno maintains comprehensive audit logs, providing a detailed record of policy enforcement actions. This transparency supports security investigations and compliance reporting endeavors.
- Integration with Existing Tools: Nirmata Enterprise for Kyverno seamlessly integrates with existing Kubernetes tools and workflows, allowing organizations to leverage their current investments in security and compliance.
How do you mitigate CVE-2023-2878 with a Kyverno policy?
The Kubernetes advisory says the issue can be mitigated before upgrading by running secrets-store-csi-driver at log level 0 or 1 via the -v flag. The following Kyverno policy restricts the secrets-store-csi-driver’s logging level, preventing the conditions that trigger the vulnerability:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-secrets-store-csi-driver-loglevel
annotations:
policies.kyverno.io/title: Prevent CVE-2023-2878
policies.kyverno.io/category: Security
policies.kyverno.io/severity: medium
policies.kyverno.io/subject: Pod, Secret, CSI-Driver
kyverno.io/kyverno-version: 1.11.0
spec:
validationFailureAction: Enforce
rules:
- name: limit-secrets-store-csi-driver-loglevel
match:
any:
- resources:
kinds:
- Deployment
- DaemonSet
validate:
message: "secrets-store-csi-driver must use log level 1 or below, CVE-2023-2878."
pattern:
containers:
- name: "secrets-store"
args: "-v=0 | -v=1"A second policy checks whether the secrets-store-csi driver is used in the cluster with token requests configured.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-if-using-csi-secrets-store-driver
annotations:
policies.kyverno.io/title: Prevent CVE-2023-2878
policies.kyverno.io/category: Security
policies.kyverno.io/severity: medium
policies.kyverno.io/subject: Pod, Secret, CSI-Driver
kyverno.io/kyverno-version: 1.11.0
spec:
validationFailureAction: Enforce
rules:
- name: check-if-using-csi-secrets-store-driver
match:
resources:
kinds:
- csidriver
validate:
message: "Potentially vulnerable to CVE-2023-2878."
pattern:
metadata:
name: "secrets-store.csi.k8s.io"
spec:
X(tokenRequests): "null"While prompt patching remains the ultimate solution, Nirmata Enterprise for Kyverno policy enforcement offers a critical interim measure to mitigate the risks posed by vulnerabilities such as CVE-2023-2878. Organizations can significantly reduce the likelihood of successful attacks and safeguard sensitive data by implementing stringent policies and continuously monitoring Kubernetes resources.
Important Reminder: Prioritize updating vulnerable components to patched versions for long-term security. Kyverno offers excellent mitigation but is not a permanent replacement for patching. For more on writing and rolling out policies like these, see the Kyverno playbook and our Kyverno security advisories hub. We used the same approach for CVE-2024-3177 and CVE-2023-5528.
How do you roll out the mitigation with Nirmata Control Hub?
The Nirmata Control Hub provides efficient policy deployment capabilities to mitigate vulnerabilities such as CVE-2023-2878 across an extensive fleet of Kubernetes clusters. The following steps outline its application in effectively addressing the vulnerability:
- Creation of Security Policy: A security policy specifically addressing CVE-2023-2878 should be defined by restricting the utilization of affected components or implementing specific security measures.
- Application of Policy to a Cluster: The security policy should be applied to particular clusters where vulnerable components are deployed or across the entire infrastructure fleet.
- Enforcement of Policy: The Nirmata Control Hub automatically enforces the policy across all clusters, ensuring immediate vulnerability mitigation.
- Monitoring and Auditing: Real-time monitoring of policy compliance is essential, and audit reports will be generated to track policy enforcement and identify any deviations.
- Remediation of Non-Compliant Clusters: Enforcing the security policy can automatically remediate non-compliant clusters, ensuring consistent protection across the entire fleet.
The Nirmata Control Hub’s centralized management, scalability, and automation capabilities make it an effective tool for rapidly deploying policies to mitigate vulnerabilities such as CVE-2023-2878 across many Kubernetes clusters. By utilizing this tool, organizations can enhance their overall security posture and reduce the risk of exploitation.
Visit the Nirmata website to learn more about Nirmata Control Hub, Nirmata Enterprise for Kyverno, and Kyverno OSS.
Frequently asked questions
How do I check whether my cluster is exposed to CVE-2023-2878?
The Kubernetes advisory gives two checks. Run kubectl get csidriver secrets-store.csi.k8s.io -o jsonpath="{.spec.tokenRequests}" to see whether token requests are configured. Then search the secrets-store container logs for csi.storage.k8s.io/serviceAccount.tokens. You are exposed only if both conditions hold: TokenRequests is set and the driver runs at log level 2 or higher.
What should I look for if tokens may already have been logged?
The advisory recommends examining your cloud provider logs for unexpected token exchanges and for unexpected access to secrets in your cloud vault. A leaked service account token can be exchanged with an external cloud provider, so those logs show whether one was used. If you find evidence of exploitation, report it to [email protected].
Why do NVD and Kubernetes give CVE-2023-2878 different CVSS scores?
The Kubernetes project, as the CVE numbering authority, scored it 6.5 with a changed scope, because a token taken from the logs can be used against an external cloud vault. NVD's own assessment is 5.5 with an unchanged scope. Both scores rate it Medium, and both treat it as a local, low-privilege attack that affects confidentiality only.