We should not upload user credentials

[suquark]

Currently we are uploading ROOT credentials and dot-files of ALL clouds to ALL clusters. This is considered a security leak.

[michaelzhiluo]

It looks like the alternative solution is to add the machine to the bucket policy?

[Michaelvll]

This is a trade-off between convenience and security. For example, a user may like to use sky launch on a cpunode, after finishing development, which will require the credentials. If we assume the instance is only used by an individual user, this would be fine, but if the user wants to share the instance with others, it will cause a problem. Maybe we need an option for users to choose whether to upload the credentials?

[concretevitamin]

The original motivation was to enable a Sky cluster to use (1) sky launch, (2) perhaps more importantly, to access private buckets on various object stores.

Maybe we need an option for users to choose whether to upload the credentials?

+1 to this solution. This is also hinted by Daniel's request here -- he would like to give collaborators SSH access to his Sky cluster.

[infwinston]

I also agree we shouldn't upload users' cloud credentials at all. For 1, I'm not sure about the use case where users would prefer to sky launch on remote VMs rather than doing it locally? I thought now we encourage users to write code locally and let sky worries about code/data sync. For 2, to enable access to private buckets, Sky can modify bucket policy and create another credential only dedicated to that S3 bucket rather than uploading a credential has full control. It seems to me we trade too much security here if it's just for easing the two use cases.

[infwinston]

For users who care about security, uploading their credentials without asking them would give a pretty negative impression.

[suquark]

I think the most frightening part is that we are trying to uploading ALL cloud ROOT credentials to ALL clusters. And it is more than root credentials, it also includes logs, command line records(azure), telemetry and all cloud settings/configurations.

  [2/7] Processing file mounts
Shared connection to 52.149.141.173 closed.
    ~/.aws/ from /Users/xxx/.aws/
Shared connection to 52.149.141.173 closed.
    ~/.config/gcloud/ from /Users/xxx/.config/gcloud/
Shared connection to 52.149.141.173 closed.
    ~/.azure/ from /Users/xxx/.azure/
Shared connection to 52.149.141.173 closed.
    ~/.ssh/sky-key.pub from /Users/xxx/.ssh/sky-key.pub

@concretevitamin @infwinston @Michaelvll @michaelzhiluo

[concretevitamin]

It's in the spirit of Sky - the task can run on any cloud, and it should be able to access the user's private data on other clouds.

If this is of grave concern, I'm +1 to disable uploading these credentials for now, because likely no users are using the above feature. Just make sure if a task runs on cloud C in {AWS, GCP}, it should be able to access private buckets in C's object store. EC2 should have a metadata service that allows this.

[github-actions[bot]]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 10 days with no activity.