|
| 1 | +# SIG K8s Infra Charter |
| 2 | + |
| 3 | +This charter adheres to the conventions described in the |
| 4 | +[Kubernetes Charter README] and uses the Roles and Organization Management |
| 5 | +outlined in [sig-governance]. |
| 6 | + |
| 7 | +## Scope |
| 8 | + |
| 9 | +The successful migration of ownership and management of all Kubernetes |
| 10 | +project infrastructure from the google.com GCP Organization |
| 11 | +(or other IaaS vendor-owned locations) to the CNCF, such that the Kubernetes |
| 12 | +project is able to sustainably operate itself without direct assistance from |
| 13 | +external vendors or entities. |
| 14 | + |
| 15 | +In other words, we seek to eradicate usage of the phrase "oh that's |
| 16 | +something that only an employee of Vendor X can do, we're blocked until |
| 17 | +they respond." |
| 18 | + |
| 19 | +### In scope |
| 20 | + |
| 21 | +Within this document, "infrastructure" is used to refer to cloud resources |
| 22 | +managed through an "infrastructure as a service" offering. This includes |
| 23 | +more than just raw compute, storage, and networking resources, since many |
| 24 | +cloud services provide a rich variety of resources for API-driven management. |
| 25 | + |
| 26 | +#### Code, Binaries and Services |
| 27 | + |
| 28 | +Code, data and policies necessary to provision, update, decommission and |
| 29 | +otherwise manage all project infrastructure as provisioned through |
| 30 | +infrastructure-as-a-service (IaaS) offerings. This includes more than raw |
| 31 | +compute, storage, and network resources traditionally bucketed under IaaS, |
| 32 | +since many cloud offerings provide a rich variety of resources via API-driven |
| 33 | +management. This may also include code and binaries which run on top of the |
| 34 | +IaaS offerings to provide services to the Kubernetes project. |
| 35 | + |
| 36 | +Given that this is a broad scope, we prefer (where possible) to delegate |
| 37 | +ownership and operation of the code / infrastructure to more directly |
| 38 | +responsible SIGs or Committees. This is largely how the SIG operated during |
| 39 | +its lifetime as a WG, driving the policies and tooling upon which SIG-owned |
| 40 | +infrastructure operates. |
| 41 | + |
| 42 | +Areas of responsibility include: |
| 43 | + |
| 44 | +- Policy definition and enforcement for areas related to project |
| 45 | + infrastructure, including: |
| 46 | + - What is in-scope/out-of-scope for project infrastructure |
| 47 | + - Who should be allowed access to which parts of project infrastructure, |
| 48 | + e.g. team definition, vetting criteria, etc. |
| 49 | + - How infrastructure should be managed, e.g. naming schemes, acceptable |
| 50 | + tooling or practices, on-call or escalation policies, etc. |
| 51 | +- Configuration management of all resources and service usage within the |
| 52 | + kubernetes.io GCP Organization, including, but not limited to: |
| 53 | + - API / Service enablement |
| 54 | + - BigQuery datasets |
| 55 | + - DNS records, e.g. for k8s.io, kubernetes.io, and other project-owned domains |
| 56 | + - GCB usage |
| 57 | + - GCP projects, instances, images |
| 58 | + - GCR repositories |
| 59 | + - GCS buckets |
| 60 | + - GKE clusters, e.g. community infra cluster, prow build clusters |
| 61 | + - GSM secrets |
| 62 | + - Google Groups |
| 63 | + - IAM roles, service accounts, and policies |
| 64 | + - KMS keys |
| 65 | + - Managed Certificates, e.g. for k8s.io, kubernetes.io, and other project-owned |
| 66 | + domains |
| 67 | +- Reports on infrastructure operation, including: |
| 68 | + - Anonymized traffic reports to show which parts of our infrastructure |
| 69 | + are seeing the most use |
| 70 | + - Auditing reports to show the current configuration of the community's |
| 71 | + infrastructure |
| 72 | + - Billing reports to show where the community's infrastructure budget is |
| 73 | + being spent |
| 74 | + |
| 75 | +In terms of subprojects, this means we own kubernetes/k8s.io and are an |
| 76 | +escalation point of last resort for more tightly scoped subprojects that |
| 77 | +live within this repo. |
| 78 | + |
| 79 | +#### Cross-cutting and Externally Facing Processes |
| 80 | + |
| 81 | +We prefer (where possible) to delegate ownership, operation and policy |
| 82 | +definition to SIGs that are more directly responsible for a given area |
| 83 | +of the project. However, we reserve the right to halt infrastructure or |
| 84 | +roll back changes if the project as a whole is being negatively impacted. |
| 85 | + |
| 86 | +Some examples for illustrative purposes |
| 87 | + |
| 88 | +##### Access Policies |
| 89 | + |
| 90 | +- We are responsible for ensuring the appropriate members of a SIG have |
| 91 | + sufficient permissions to troubleshoot and manage their app or |
| 92 | + infrastructure. |
| 93 | +- However, we will NOT grant overly broad permissions to an overly broad |
| 94 | + group of people. We will collaborate with SIGs to ensure access is |
| 95 | + appropriately scoped. |
| 96 | +- We WILL ensure the appropriate set of CNCF staff have access to act as |
| 97 | + an escalation path of last resort |
| 98 | +- We MAY revoke access in the event of a security-related incident |
| 99 | + |
| 100 | +e.g. SIG Release is responsible for who gets what level of access to |
| 101 | +infrastructure used by the release-engineering subproject to cut a Kubernetes |
| 102 | +release |
| 103 | + |
| 104 | +##### Artifact Hosting |
| 105 | + |
| 106 | +- We are not responsible for promoting into production artifacts that belong |
| 107 | + to subprojects owned by other SIGs. |
| 108 | +- However, we MAY revert changes that prevent artifact promotion from |
| 109 | + functioning. |
| 110 | + |
| 111 | +e.g. SIG Storage is responsible for declaring which CSI-related images should |
| 112 | +be promoted to production, SIG Release is responsible for ensuring those |
| 113 | +images make it to production, and SIG K8s Infra is responsible for ensuring |
| 114 | +that production exists in the first place |
| 115 | + |
| 116 | +##### Community Infra Cluster |
| 117 | + |
| 118 | +- We are responsible for ensuring a community-owned GKE cluster is available |
| 119 | + to run apps owned by other SIGs. |
| 120 | +- However, we are NOT responsible for ensuring proper functionality of those |
| 121 | + apps. That is left to the SIGs. |
| 122 | + |
| 123 | +e.g. SIG Scalability is responsible for ensuring perfdash.k8s.io displays |
| 124 | +valid data |
| 125 | + |
| 126 | +##### Project Infrastructure Budget |
| 127 | + |
| 128 | +- We are responsible for enforcing policy on what is considered in-scope and |
| 129 | + out-of-scope for project infrastructure (and thus, where we spend our |
| 130 | + infrastructure budget) |
| 131 | +- Crafting such policy is done in collaboration with the Steering Committee |
| 132 | + (owns project spending) and SIG Architecture (owns Kubernetes definition) |
| 133 | +- We MAY delete or scope down infrastructure in the event of unexpected or |
| 134 | + undue spend |
| 135 | + |
| 136 | +e.g. SIG K8s Infra will deny requests to host artifacts for projects that are |
| 137 | +formerly part of or adjacent to the Kubernetes project (e.g. helm, cri-o) |
| 138 | + |
| 139 | +##### Public Names |
| 140 | + |
| 141 | +- We are responsible for enforcing policy on what is considered appropriate |
| 142 | + or inappropriate for the names of public-facing entities such as DNS |
| 143 | + records and Google Group names |
| 144 | +- Crafting such policy is done in collaboration with the Steering Committee, |
| 145 | + SIG Architecture, and SIG Contributor Experience |
| 146 | + |
| 147 | +e.g. Group names that are used to communicate upon behalf of the project such |
| 148 | +as `[email protected]` are vetted by SIG Contributor Experience, |
| 149 | +group names that are used for RBAC or IAM bindings are vetted by SIG K8s Infra. |
| 150 | + |
| 151 | +##### Secrets and Credentials |
| 152 | + |
| 153 | +- We are responsible for ensuring secure storage and retrieval of secrets |
| 154 | + such as passwords, tokens, keys, etc. |
| 155 | +- However, we are NOT responsible for ensuring the value of those secrets |
| 156 | + is valid. |
| 157 | +- We MAY delete or deactivate secrets in the event of a security-related |
| 158 | + incident |
| 159 | + |
| 160 | +e.g. SIG Contributor Experience is responsible for ensuring valid Slack API |
| 161 | +credentials exist for proper functioning of slack-infra |
| 162 | + |
| 163 | +##### Security Response |
| 164 | + |
| 165 | +- Overriding all of the above, we MAY revoke, delete, or deactivate |
| 166 | + infrastructure, services or access in the event of a security-related |
| 167 | + incident. |
| 168 | +- This depends on responsiveness of the owning SIG, and urgency and severity |
| 169 | + of the incident being responded to |
| 170 | + |
| 171 | +e.g. SIG K8s Infra may force rotation of prow build cluster credentials if |
| 172 | +appropriately credentialed members of SIG Testing are not available |
| 173 | + |
| 174 | +### Out of scope |
| 175 | + |
| 176 | +We are not resonsible for code that runs _on_ project infrastructure, with |
| 177 | +the exception of: |
| 178 | + |
| 179 | +- subprojects of this SIG (as listed in [`sigs.yaml`], which is more likely |
| 180 | + to be kept up to date than this charter) |
| 181 | +- code we share responsibility for (as listed in the [Cross-cutting and |
| 182 | + Externally Facing Processes] section) |
| 183 | + |
| 184 | +We are not responsible for the management of nor in the escalation path for |
| 185 | +supporting non-IaaS offerings used by the Kubernetes project that are |
| 186 | +managed by other subprojects under other SIGs. For example, problems with |
| 187 | +GitHub should be routed to SIG Contributor Experience. |
| 188 | + |
| 189 | +We are not responsible for managing infrastructure which has not yet been |
| 190 | +migrated to the CNCF. For example, problems with prow.k8s.io should be routed |
| 191 | +to SIG Testing. |
| 192 | + |
| 193 | +## Roles and Organization Management |
| 194 | + |
| 195 | +This sig adheres to the Roles and Organization Management outlined in |
| 196 | +[sig-governance] and opts-in to updates and modifications to [sig-governance]. |
| 197 | + |
| 198 | +We may revise this portion of the charter when it comes time to talk about |
| 199 | +providing a level of support and responsiveness that one might reasonably |
| 200 | +expect from a globally distributed open source project. |
| 201 | + |
| 202 | +[sig-governance]: https://git.k8s.io/community/committee-steering/governance/sig-governance.md |
| 203 | +[Kubernetes Charter README]: https://git.k8s.io/community/committee-steering/governance/README.md |
| 204 | +[lazy consensus]: http://en.osswiki.info/concepts/lazy_consensus |
| 205 | + |
| 206 | +[kubernetes-dev@]: https://groups.google.com/forum/#!forum/kubernetes-dev |
| 207 | +[sig-k8s-infra@]: https://groups.google.com/forum/#!forum/kubernetes-sig-k8s-infra |
| 208 | +[kubernetes/k8s.io]: https://git.k8s.io/k8s.io |
| 209 | +[`sigs.yaml`]: https://git.k8s.io/community/sigs.yaml |
0 commit comments