Security Vulnerabilities found in secrets-store-csi-driver-provider-gcp

kalpesh6331 commented 1 year ago

Description

We are using secrets-store-csi-driver-provider-gcp to fetch sensitive data from GCP secret manager into our application. This application is mission critical and has been running in production since couple months. As a part of CIS benchmarks, we need to run different scans on the runtime Prisma Cloud (from PaloAlto networks) has detected following vulnerabilities.

We would like to know if these can be fixed or already fixed in any future releases. If it is fixed via configuration (changes in helm values), would it affect any functionality or working of csi-driver?

Vulnerabilities:

Do not share the host's network namespace
Mount container's root filesystem as read only
Do not share the host's UTS namespace
Do not disable default seccomp profile
Use PIDs cgroup limit
Container is running as root
Restrict container from acquiring additional privileges
Do not set mount propagation mode to shared
Do not use privileged containers
Verify AppArmor profile, if applicable

Specifications

KEDA Version: 2.8.2
csi_driver: k8s.gcr.io/csi-secrets-store/driver:v1.2.4
csi_driver_crds: k8s.gcr.io/csi-secrets-store/driver-crds:v1.2.4
csi_node_driver_registrar: k8s.gcr.io/sig-storage/csi-node-driver-registrar:v2.5.1
sig_storage_liveness_probe: k8s.gcr.io/sig-storage/livenessprobe:v2.7.0
csi_gcp_provider_plugin: us-docker.pkg.dev/secretmanager-csi/secrets-store-csi-driver-provider-gcp/plugin@sha256:cb491d4af4776ac352aac415676918fa7cd4ef1671e71c579175ef3e2820af09

kalpesh6331 commented 1 year ago

Could anyone please update on this?

amitmodak commented 1 year ago

Thank you for reporting this issue! We have added this to our roadmap and will look into it.

As you have pointed out, it looks like most of these vulnerabilities can indeed be fixed via configuration changes. However, we will need to do extensive testing of the provider and the driver to make sure there is no impact on functionality due to these changes.

NaMNDV commented 7 months ago

[Progress Comment] Hi,

Below are the provider fixes for the configurations:

Do not share the host's network namespace
Fixed #289

Mount container's root filesystem as read only
Fixed #292

Do not share the host's UTS namespace
Fixed #289, #290

Do not disable default seccomp profile
FIxed #331

Use PIDs cgroup limit
NA

Container is running as root
In Progress (driver requirements)

Restrict container from acquiring additional privileges
Fixed #321

Do not set mount propagation mode to shared
Fixed #318

Do not use privileged containers
Fixed #321

Verify AppArmor profile, if applicable
In Progress

A few are in progress and we are constantly looking into that. Till then could you please verify the fixes from your end by running benchmarking tools at your end.

Soon we will discuss vulnerabilities and configuration fixes with our dependencies e.g. driver, livenessprobe ...

jagtapa commented 7 months ago

Hello @NaMNDV

Thank you for the information. Could you please verify the release version in which the mentioned vulnerabilities have been addressed? We will conduct testing based on that information to confirm the resolution.

NaMNDV commented 7 months ago

Sure, it's 1.4.0

jagtapa commented 4 months ago

Greetings team,

We've noticed that the secrets-store-csi-driver.yaml includes the securityContext option:

      fieldPath: spec.nodeName
      imagePullPolicy: {{ .Values.linux.image.pullPolicy }}
      securityContext:
        privileged: true

However, its default values are not currently present in the values.yaml file for easy overriding. Could you please include it in the default values.yaml file so that it can be overridden externally & we can test it?

And also confirm about this vulnerability "Verify AppArmor profile, if applicable" whether its fixed or not in 1.4.0 release @NaMNDV

NaMNDV commented 3 months ago

Thanks @jagtapa for pointing this out.

I'll raise a PR to update the driver: https://github.com/kubernetes-sigs/secrets-store-csi-driver/blob/main/charts/secrets-store-csi-driver/templates/secrets-store-csi-driver.yaml

and corresponding values.yaml: https://github.com/kubernetes-sigs/secrets-store-csi-driver/blob/main/charts/secrets-store-csi-driver/values.yaml

also the manifest_staging: https://github.com/kubernetes-sigs/secrets-store-csi-driver/tree/main/manifest_staging charts

Regarding AppArmor profile: The AppArmor profile is not applicable and is not applied in 1.4.0 release

NaMNDV commented 3 months ago

      fieldPath: spec.nodeName
      imagePullPolicy: {{ .Values.linux.image.pullPolicy }}
      securityContext:
        privileged: true

https://github.com/kubernetes-sigs/secrets-store-csi-driver/pull/1469#pullrequestreview-1933329018 the security configuration is a hard-requirement for the driver and can not be changed. The driver won't work by configuring this with other values of securityContext.privilaged . Thus we can not make the security context configurable.

If future has some other configurable fields in the securityContext, we may think of this approach later.

jagtapa commented 2 months ago

@NaMNDV:

I concur with your point that setting this flag to true is necessary. We also need to incorporate additional parameters into the securityContext. However, because the option below

securityContext: privileged: true

is absent in the default values file, we are unable to add or test other security parameters. It's important to note that we should not modify privileged: true. Nevertheless, having this parameter in the default values file would provide us with the flexibility to add other securityContext configurations.

Please share your thoughts on this matter.

GoogleCloudPlatform / secrets-store-csi-driver-provider-gcp