Secrets field in NodeGetInfoRequest

[bells17]

Now, CSI specification defines a secrets field in some gRPC requests.

However, NodeGetInfoRequest does not have this field, meanwhile getting node information might require some credentials with reading access to work properly.

I think we need an optional secrets field in NodeGetInfoRequest.

---

In my case, I creating a CSI Driver for cloudstack. If the cloudstack has a data server, it can use metadata for node id and topology. But if the cloudstack doesn't have a data server, need to use cloudstack API to get node id and topology.

[julian-hj]

@bells17 normally, for this type of use case, we assume that the CSI plugin will receive secrets at startup time from whatever process or container is used to run the plugin. Secrets that appear in the RPC are intended for cases where consumers of the storage have heterogeneous access, and the plugin should get different secrets from different users.

In the case of NodeGetInfo, it is hard to imagine that a CO would ever call the RPC with different credentials for different users.

So, is there some reason that you cannot simply furnish credentials to your plugin at installation time?

[bells17]

@julian-hj Thank you for explaining about the use case.

In the case of NodeGetInfo, it is hard to imagine that a CO would ever call the RPC with different credentials for different users.

So, is there some reason that you cannot simply furnish credentials to your plugin at installation time?

Yes, I want to use the same credentials in NodeGetInfo.

But in cloudstack, API KEY is associated with the user. And, I can't set detailed permissions with cloudstack. (So the API KEY can be used to other than get the node information)

And the case of using Kubernetes for CO, the CSI Driver run to all node. In that situation, the credentials can be seen from SSH users in the node through the proc env or the mount volume.

I think that if the secrets field exists in each RPC request, the CSI Driver no longer needs to have credentials(e.g. API KEY). (In that case, in Kubernetes, the credentials are got from Kubernetes API Server before each RPC request, and each CSI Sidecar applications don't have the credential in the proc env or the mount volume)

[julian-hj]

But in the case of Kubernetes, and I suspect every other CO also, NodeGetInfo is called during plugin registration, so there is no end-user with credentials to provide.

https://github.com/kubernetes/kubernetes/blob/dde6e8e7465468c32642659cb708a5cc922add64/pkg/volume/csi/csi_plugin.go#L134

What did you have in mind for providing the necessary secrets to the kubelet so that it knows what to pass to NodeGetInfo?

[bells17]

Um...Sorry. I didn't think how to provide the necessary secrets to the kubelet.

[julian-hj]

I'd suggest that if you aren't comfortable with mounting secrets into the container for your CSI plugin, maybe you could add an init container that consumes the secret, and uses it to look up the node info. That way the container will be very short lived, and a malicious SSH user won't be able to find the secret. Your CSI node plugin could then consume the node info directly, and not require secrets.

[bells17]

I see. Thank you!