Secrets field names #206
Description
Field Name Length
I just double-checked the spec, and there is never more than a single type of secrets field per RPC. The field names are unnecessarily verbose and result in language bindings and subsequent developer code that is not as clean or succinct as it could be.
Please consider simplifying the secrets fields to secrets.
Also, if the argument against this is that RPCs may have multiple secrets packages in the future, then the fields should become more verbose as the future of CSI may also contain snapshots, pools, etc. Then controller_create_secrets is no longer unique unless it becomes controller_create_volume_secrets.
At the very minimum the field names should drop the service prefix as it's redundant.
However, again, these are not RPC message definitions. The scope of fields is tied to the RPC message itself, and thus information like the service prefix as necessarily unique is quite improbable. To that end, so is everything but secrets itself.
Field Name Permanence
The names of the secrets-related fields should be declared untouchable once decided upon. This is due to their inherent, sensitive nature. Logging middleware and other applications may elect to omit sensitive data when storing or producing output. Changing the names of the fields in the future could result in the leaking of sensitive data.
Summary
- Please simplify the secrets field names to
secrets. - Please never change these field names again
cc @saad-ali