-
Notifications
You must be signed in to change notification settings - Fork 946
Open
Labels
area/accessDefine who has access to what via IAM bindings, role bindings, policy, etc.Define who has access to what via IAM bindings, role bindings, policy, etc.area/prowSetting up or working with prow in general, prow.k8s.io, prow build clustersSetting up or working with prow in general, prow.k8s.io, prow build clustersarea/release-engIssues or PRs related to the Release Engineering subprojectIssues or PRs related to the Release Engineering subprojectkind/cleanupCategorizes issue or PR as related to cleaning up code, process, or technical debt.Categorizes issue or PR as related to cleaning up code, process, or technical debt.kind/documentationCategorizes issue or PR as related to documentation.Categorizes issue or PR as related to documentation.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.Indicates that an issue or PR should not be auto-closed due to staleness.priority/backlogHigher priority than priority/awaiting-more-evidence.Higher priority than priority/awaiting-more-evidence.sig/k8s-infraCategorizes an issue or PR as relevant to SIG K8s Infra.Categorizes an issue or PR as relevant to SIG K8s Infra.
Description
Caught via #1718 (comment)
I've done the following pattern a few times now (most recently #1696 (comment)):
- someone needs to pass a secret to me, wonders how to transfer it
- I setup a secretmanager secret in the relevant project
- intended to be k8s secrets in a cluster: the project hosting the cluster
- kubernetes-public for apps running on aaa
- k8s-infra-prow-build-trusted for prow jobs or components runnong on prow-build-trusted
- etc.
- intended to be k8s secrets in a cluster: the project hosting the cluster
- Setup appropriate permissions on the secret (need to figure out a consistent pattern here)
- Org admins should implicitly get access via their role/owner on the organization
- Give some sort of "oncall" team ownership of the secret and its versions for break-glass cases
- Give whomever is handing the secret to us write access to the secret version
- Setup labels on the secret
app: fooif its for an app in thefoodir running on aaagroup: sig-fooif the app is owned by sig-foo- ??? maybe the namespace the secret is destined for?
- Request that for things destined to be k8s secrets, people store an actual secret manifest yaml in the secret
Put it all together and this allows for relatively simple / safe deployment: https://github.com/kubernetes/k8s.io/tree/main/slack-infra#how-to-deploy
Problems with the above:
- it needs to be documented instead of me just happening to kinda/sorta do something consistent
- the secret creation should be scripted
Metadata
Metadata
Assignees
Labels
area/accessDefine who has access to what via IAM bindings, role bindings, policy, etc.Define who has access to what via IAM bindings, role bindings, policy, etc.area/prowSetting up or working with prow in general, prow.k8s.io, prow build clustersSetting up or working with prow in general, prow.k8s.io, prow build clustersarea/release-engIssues or PRs related to the Release Engineering subprojectIssues or PRs related to the Release Engineering subprojectkind/cleanupCategorizes issue or PR as related to cleaning up code, process, or technical debt.Categorizes issue or PR as related to cleaning up code, process, or technical debt.kind/documentationCategorizes issue or PR as related to documentation.Categorizes issue or PR as related to documentation.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.Indicates that an issue or PR should not be auto-closed due to staleness.priority/backlogHigher priority than priority/awaiting-more-evidence.Higher priority than priority/awaiting-more-evidence.sig/k8s-infraCategorizes an issue or PR as relevant to SIG K8s Infra.Categorizes an issue or PR as relevant to SIG K8s Infra.
Type
Projects
Status
Backlog