search

vmware-tanzu / velero

Backup and migrate Kubernetes applications and their persistent volumes
https://velero.io
Apache License 2.0
8.59k stars 1.39k forks source link

Optionally drive all object storage access through the velero server #2331

Open TJM opened 4 years ago

TJM commented 4 years ago

Describe the problem/challenge you have

Our object storage (PureStorage Flashblade) is not accessible to end users (clients), only the servers. Unfortunately, the velero client appears to connect directly to the object storage for at least sub-commands like "logs" and the "--details" from describe, and likely others.

Describe the solution you'd like

I would like the velero client to request the velero server process to interact with the object storage and relay the information to the client (proxy?). I am sure that there would be some case where this would need to be optional. I honestly think that the client should never have credentials to access anything in object storage.

Anything else you would like to add:

We can workaround this by ssh-ing to a host in the datacenter and running the velero client, or running it from a pod.

Environment:

bgagnon commented 4 years ago

I honestly think that the client should never have credentials to access anything in object storage.

I am pretty sure the velero client uses temporary URLs signed by the velero server in cases where it needs to hand off direct access to objects in storage. The client is never given the credentials.

Nevertheless, I think it could be possible that the client has no network connectivity to the object storage while having connectivity to the velero server and Kubernetes API. This would still require a full proxying of object storage calls.

skriss commented 4 years ago

I am pretty sure the velero client uses temporary URLs signed by the velero server in cases where it needs to hand off direct access to objects in storage. The client is never given the credentials.

That's correct.

Regardless, I agree with the sentiment of this enhancement request and would like to find a way to do this as well - using pre-signed URLs has a bunch of limitations.

TJM commented 4 years ago

With the "security" implications aside (as I think thats something that should be handled outside of github issues), I think it would be fairly common to have a NAS device that is not externally accessible. I know I could create a load balancer VIP and point it towards the NAS, and set the "public" URL to that, but I really don't like the idea. We do have a VIP for the K8s API Server, which is apparently providing port forwarding to access the velero backend? (I think)

nrb commented 4 years ago

IMO, if we pursued this, I would prefer to make it the only way for the client to access the object store - maintaining the two code paths for an extended period of time would be onerous.

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] commented 3 years ago

Closing the stale issue.

TJM commented 3 years ago

That's great. Thanks bot. Can we have this re-opened. It is still a problem for us. We still do not allow end users to have direct access to the storage array. Right now, that means that we have to have a sort of "bastion" host where they can run the velero commands, which sucks.

kaovilai commented 4 months ago

Can be satisfied with https://github.com/vmware-tanzu/velero/issues/6167