Open RomanBednar opened 2 months ago
if networkEndpointType
is unset, that means the csi driver would matching any account with or without networkEndpointType
; if you only want to match networkEndpointType: privateEndpoint
accounts, then you need to specify this parameter in storage class. @RomanBednar
if
networkEndpointType
is unset, that means the csi driver would matching any account with or withoutnetworkEndpointType
@andyzhangx This is the actual issue, simplified. With this behavior we can not tell the driver to "avoid" private endpoint accounts. Either we request a private one specifically (predictable) or leave unset which means driver can match both private or public (unpredictable). And what we need is a way to reliably not match private endpoint accounts making it predictable.
@andyzhangx Do you think this could be considered a bug? We're looking for a fix that we could ship soon and it depends on the decision made for this issue.
I've found a fix that might work for now - if we set parameters to have a tag and require matching the tag, the driver will always create it's own storage account with first volume provisioned and then reuse it (unless there's one with a matching tag, which is unlikely yet still possible). With this we should be almost certain we don't match "foreign" storage accounts right? Or is it a bad idea?
if networkEndpointType is unset, that means the csi driver would matching any account with or without networkEndpointType
I think that's a bug. It should match an usable account, not just any account. A private account + StorageClass with networkEndpointType: ""
will lead to a PV that cannot be mounted today. Maybe there is another storage account that does not require private endpoints and would fit that CreateVolume call better.
if networkEndpointType is unset, that means the csi driver would matching any account with or without networkEndpointType
I think that's a bug. It should match an usable account, not just any account. A private account + StorageClass with
networkEndpointType: ""
will lead to a PV that cannot be mounted today. Maybe there is another storage account that does not require private endpoints and would fit that CreateVolume call better.
@jsafrane CSI driver does not know whether the account is usable or not, it depends on the application pods, whether it's running on allowed vnet node. there is a parameter mapping rule: in general, if the value is not specified, the driver would just check the corresponding properties.
@RomanBednar I think best way to solve this issue is specifying networkEndpointType: privateEndpoint
in sc though tag also works.
@andyzhangx I've tested that and it rather masks the problem and poses a few others: if we set networkEndpointType: privateEndpoint
the driver will always configure a private endpoint on new storage account. And if there already is one that matched it will update it with private endpoint - but we don't know which account gets updated.
Then we should still allow "public" storage accounts for CSI driver to exist alongside arbitrary "private" ones (supported) and with this solution it would not be possible.
While there is an existing storage account in Azure which is configured to use private endpoints and disallow public network access the driver can match this storage account even with
networkEndpointType
SC parameter unset. However it will not configure a private endpoint for worker subnet becausenetworkEndpointType
is not set toprivateendpoint
- this will cause volume mounts to fail on worker nodes.This seems like a bug and the driver probably should not match "private" storage accounts if
networkEndpointType
parameter is omitted or set to""
. Maybe there is some other parameter(s) for this scenario that we missed?Driver version: v1.30.3
Reproducer:
imageregistryrbednah6mbs
)Storage Class has
networkEndpointType: ""
(or omitted):Driver matches an existing storage account:
The storage account matched is private:
With this configuration worker nodes can not mount any newly provisioned volumes as there is no private endpoint configured for the worker subnet:
NOTE: If I create SC with
networkEndpointType=privateendpoint
and provision a volume with it, the driver will set the private endpoint correctly on the existing storage account which fixes the mount issue for any other consecutive mounts that would reuse this storage account. This can be a temporary workaround.Followup question: We have the above mentioned configuration in OpenShift private clusters where registry operator creates it's own storage resources including a (private) storage account and CSI provisioning happens after that. Even if this issue is resolved still the driver can in similar scenarios reuse "foreign" storage accounts and we're not sure if that's a good practice. Later, we would like to introduce a fix for this as well. Is there a recommended way to ensure the driver will never reuse a storage account not created by it? Could storageaccount or createaccount parameter be sufficient and safe solution?