Simplify credentials from 8 to 3

[saad-ali]

Fixes #198

Simplify secrets by specifying a secret per use case instead of per operation (reducing 8 possibilities to 3):

1. create_delete_volume_secrets
   • Grants ability to create and delete volume requests.
   • Passed to CreateVolume() and DeleteVolume().
2. volume_secrets
   • Secrets required to access a volume, independent of any consumer.
   • Example: an encryption key for volume.
   • Passed to ControllerPublishVolume(), ControllerUnpublishVolume(), NodeStageVolume(), NodeUnstageVolume(), NodePublishVolume(), NodeUnpublishVolume().
3. workload_secrets
   • Secrets required to auth a specific consumer of a volume.
   • Example: A single NFS share that permits multiple users access via different credentials.
   • Passed to NodePublishVolume(), NodeUnpublishVolume()

Why? Exposing 8 credentials to end users is confusing for end users (it requires them to understand the inner workings of CO to SP communications), and difficult for COs to do.

[sbezverk]

@saad-ali Would it be a bit more precise to use secret instead of secrets in the proposed new names? I suspect this will be mapped to a single object by CO, like k8s' Secret. Having secrets in the name might lead to confusion.

[saad-ali]

@saad-ali Would it be a bit more precise to use secret instead of secrets in the proposed new names? I suspect this will be mapped to a single object by CO, like k8s' Secret. Having secrets in the name might lead to confusion.

I was thinking about that, and it is accurate from the Kubernetes perspective that a single secret can contain the entire map, but from the CSI/Plugin perspective, there is no concept of a Kubernetes secret object, and as far CSI and the Plugin are concerned these are maps containing one or more secrets. So I'd prefer secrets instead of secret.

[saad-ali]

Slept on this, and realized it might be too extreme, and block out the ability for plugins to choose which calls to accept which secrets on (the same secret may not be required in all calls and requiring it everywhere may mean giving access to secret in components the plugin may not want to). Closing this, will comment on alternative on the original issue.