Take advantage of csi_secret in CSI 1.0
#167
Comments
pohly
added a commit
to pohly/external-provisioner
that referenced
this issue
Nov 21, 2018
When running at glog level >= 5, external-provisioner logged the full CreateVolumeRequest, including the secrets. Secrets should never be logged at any level to avoid accidentally exposing them. We need to filter out the secrets. With older CSI versions, that could have been done based on the field name, which is still an option should this get backported. With CSI 1.0, a custom field option marks fields as secret. Using that option has the advantage that the code will continue to work also when new secret fields get added in the future. For the sake of simplicity, JSON is now used as representation of the string instead of the former compact text format from gRPC. That makes it possible to strip values from a map with generic types, instead of having to copy and manipulate the real generated structures. Another option would have been to copy https://github.com/golang/protobuf/blob/master/proto/text.go and modify it so that it skips secret fields, but that's over 800 lines of code. Ultimately this new package should live in a "csi-common" repo and also include other utility code, like logGRPC itself. Fixes: kubernetes-csi#82, kubernetes-csi#167
Closed
Merged
kbsonlong
pushed a commit
to kbsonlong/external-provisioner
that referenced
this issue
Dec 29, 2023
Prow update master
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
CSI 1.0 decorates sensitive fields with
csi_secret. Let's take advantage of this feature to programmatically ensure no sensitive fields are ever logged by this side car container.The text was updated successfully, but these errors were encountered: