-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Driver can display the secret content of node-expand-secret-name #1372
Comments
/assign I have a patch to sanitize specific RPC req types, but before opening PR I'd like to get feedback on issue severity. The severity is probably depends on possibility to have permissions high enough to create or modify StorageClass, but not as high as cluster admin who can print secrets in a simpler way. |
We discussed it on today's sig-storage triage meeting and we agreed that it should be fixed by sanitizing requests, but only when debug log level is enabled: if klog.V(4).Enabled() {
klog.Infof("%s called with request: %s", info.FullMethod, sanitize(req))
} Then it won't get called in production or wherever performance is required. |
For production we actually use log level 4. The pdcsi driver does not actually require any secrets though? Maybe we need to look at ways to disallow/ignore secrets being passed in the first place. |
Yes, the CSI driver does not need any secrets, it just logs them and then ignores them. Currently it's not possible to tell CSI sidecars / kubelet what secrets the driver actually uses and I am not sure it's the right direction - it could be error prone to adding new method / secret. |
If there was a CSIDriver field that said whether the driver used secrets at all, then tere could be eg an admission webhook that only let known drivers exposing secrets to be installed. (eg, this driver doesn't use secrets at all). I understand there'd be backwards compatibility issues with this, but it's an idea. |
Malicious user can put a secret in request as explained here: kubernetes-sigs#1372.
Malicious user can put a secret in request as explained here: kubernetes-sigs#1372.
Malicious user can put a secret in request as explained here: kubernetes-sigs#1372.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/remove-lifecycle rotten |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
Malicious user can put a secret in request as explained here: kubernetes-sigs#1372.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
What happened?
An user with permissions to create or modify
StorageClass
may print anySecret
.The problem comes from a
klog
print which is not sanitized:The comment says that secrets are not included in any RPC message, however there many RPC messages that might include secrets. For example
NodeExpandVolume
as explained here. If one can add:to the
StorageClass
, then after PV resize one can see in logs:Note that there are 7 more RPC message types with secrets listed here.
GCP CSI driver does not seem to use these features, so the threat may come only from malicious user with elevated permissions who intentinally want to expose secrets.
What did you expect to happen?
Log print to be sanitized. E.g.:
How can we reproduce it?
Create pvc/pod
Update csi driver log to Debug
Resize the volume capacity
Check csi driver logs
Anything else we need to know?
n/a
/cc @msau42 , @mattcary , @cjcullen, @tallclair, @jsafrane
The text was updated successfully, but these errors were encountered: