@User Hi Jackie, I have a few more questions for you before I embark on the great Upgrading of the google configuration. My boss asked this set of questions and I was hoping to have a dialogue with you before I scoped work out for the upgrade. Our company has many projcts that we'd like to keep mutually exclusive for the sake of customer privacy. Have you any quickish/obvious/metaflow centric ideas/solutions to the following authn/authz problems? 1. How do I ensure user A who can only access project Foo, cannot see anything user B submitted to project Bar a. Both in metaflow UI and via metaflow api client 2. How do I ensure no single user can explode cloud bill 3. How do I grant direct access to kubernetes (

gcloud container clusters get-credentials

) without allowing user A to SSH into pod running work in project Bar and e.g. run

gsutil -m cp -r <gs://project-bar/*>

<gs://project-foo/>

4. How do we tie all actions that touch sensitive data back to IAM identities managed in terraform

Sure, welcome back. 1. In Metaflow, the concept of Metaflow projects and namespaces are organizational conveniences only, and are not true "security" features. In OSS Metaflow, I would say the truly secure way to isolate access is to stand up separate Metaflow stacks. This of course limits the granularity with which access control can be done, and may present more operational overhead. We can offer ideas on single stack solutions (which would require significantly more reading/config/etc.). 2. Quotas is what you need. The obvious option is to leverage ability to set resource quotas Kubernetes namespaces. Roughly speaking, users would submit their jobs to specific k8s namespaces that have their resource consumption upper bounded. An even simpler approach is simply to place a global upper bound on how large the node group can get. This takes care of the global cloud bill, but may result in starvation / fairness issues. 3. Can you elaborate on the "direct access to kubernetes". Is the use case still that of users running Metaflow flows on Kubernetes? Or some non-metaflow usage of the cluster? 4. Can you elaborate on what you mean by sensitive data? Need more details.