Try to simplify storage permissions

[spiffxp]

Followup based on #2005

For whatever reason, I am still confused by exactly which permissions are available to whom on which GCS buckets. I've started consulting a spreadsheet I put together to help figure out what makes sense from a policy perspective. I've been trying keep GCS IAM best practices in mind, as well as the guidance that basic roles aren't a great idea for production environments.

Three things currently bug me:

1. whether uniform bucket-level access is enabled at bucket-creation time determines whether convenience roles like roles/viewer are granted storage.objects.get (ref: https://cloud.google.com/storage/docs/access-control/iam-roles#basic-roles-modifiable)
2. there's no predefined role that grants storage.buckets.list on a per-bucket basis except roles/storage.admin
3. some projects have buckets that are more sensitive than others (e.g. terraform resources for disparate privilege levels, logs containing PII), and it's unclear how to ensure basic roles are denied permissions to these buckets, while retaining admin/read privileges for other buckets

What I think we can do to address:

1. Set constraints/storage.uniformBucketLevelAccess at the org level (ref: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints). This wouldn't suddenly wipe out existing per-object ACLs. The only per-object ACLs I am currently aware of are related to billing data in kubernetes-public, and I'm optimistic they can be removed in favor of the bucket's IAM policy.
2. research if this is feasible or worthwhile by creating a custom storage.bucketLister role and trying to apply it on a per-bucket basis (we do this today with secretmanager.secretLister)
3. based on 1 and 2, determine if it makes sense to prune convenience bindings like projectOwner:roles/legacyBucketOwner, and replace with direct roles/storage.admin or a custom storage admin role that remove storage.buckets.delete

References:

• https://cloud.google.com/storage/docs/access-control/iam#best_practices
• https://cloud.google.com/storage/docs/access-control/iam#project-level_roles_vs_bucket-level_roles
• https://cloud.google.com/storage/docs/access-control/iam#convenience-values
• https://cloud.google.com/storage/docs/access-control/iam-roles#basic-roles-modifiable
• https://cloud.google.com/storage/docs/access-control/iam-permissions

[spiffxp]

#2010 should allow us to perform 1 (should research more before flipping that switch though)

Also ensures org admins can list, get, update any bucket within the org. Specifically does nothing about whether they can access multipartUploads or objects.

[spiffxp]

Based on review of #2094, here are some example buckets that appear to have per-object ACLs enabled:

• audit/projects/k8s-gcr-audit-test-prod/buckets/artifacts.k8s-gcr-audit-test-prod.appspot.com/metadata.txt
• audit/projects/k8s-infra-e2e-boskos-001/buckets/kubernetes-staging-485128143e-asia/metadata.txt
• audit/projects/k8s-infra-e2e-boskos-001/buckets/kubernetes-staging-485128143e-eu/metadata.txt
• audit/projects/k8s-infra-e2e-boskos-001/buckets/kubernetes-staging-485128143e/metadata.txt
• (basically all kubernetes-staging-{sha} buckets created by kube-up.sh)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ameukam]

/area infra
/area audit
/remove-lifecycle stale

[spiffxp]

/area access