From 53a49bbda54833e1a96d6fd5bec7fef4e77ef93f Mon Sep 17 00:00:00 2001 From: Jeremy Olmsted-Thompson Date: Mon, 6 Apr 2020 14:07:42 -0700 Subject: [PATCH] Update sig-multicluster/namespace-sameness-position-statement.md Co-Authored-By: Tim Hockin --- .../namespace-sameness-position-statement.md | 66 +++++++++++++++++++ 1 file changed, 66 insertions(+) diff --git a/sig-multicluster/namespace-sameness-position-statement.md b/sig-multicluster/namespace-sameness-position-statement.md index 449bd162b..11fdfc52f 100644 --- a/sig-multicluster/namespace-sameness-position-statement.md +++ b/sig-multicluster/namespace-sameness-position-statement.md @@ -33,3 +33,69 @@ particular, to create namespaces in them. **For a set of related clusters governed by a single authority, all namespaces of a given name are considered to be the same namespace. A single namespace should have a consistent owner across the set of clusters.** + +## Appendix + +This position statement is intentionally very abstract, with the goal of not +being overly prescriptive. The following examples are HYPOTHETICAL, but +hopefully make the statement clearer. + +### Example 1: Namespace creation + +Consider an organization that runs two clusters, "A" and "B". They have a +cluster-ops team which is responsible for keeping those clusters alive and +healthy. They also have app-teams, "foo" and "bar" which use those clusters. + +Cluster-ops owns the creation of namespaces in both clusters. They can choose +to delegate the ability to create namespaces to foo-team and bar-team, but any +namespace name that is allocated in "reserved" in all clusters. How the +delegation works is an area for innovation, but some possible examples +include: + * A self-service portal which allocate a name in a global database and + creates the namespace on the user's behalf + * Tooling that allocates a name in a global database and issues a credential + to the user which is checked in an admission controller + * An admission controller which requires namespaces be prefixed by the team + name + +However they choose to delegate (or not), once foo-team requests a namespace +called "database" in cluster A, no other team may request a namespace called +"database" in cluster B. That name is taken. + +### Example 2: RBAC sync + +Consider the same organization from example 1. As with many large-sized +organizations, they alreadyhave a central LDAP server which stores policies +about who is supposed to be able to access what systems. They enforce this by +converting those policies into Kubernetes RBAC rules and pushing them down into +their clusters. + +Cluster-ops runs a metrics service in each cluster. The RBAC for this service +should be the same in each cluster (i.e. the same set of people administer it, +regardless of which cluster). The LDAP-to-RBAC sync process can assume that +the "metrics" namespace in each cluster should get the same RBAC rules. + +If there are special RBAC rules that need to be applied in some clusters (e.g. +clusters in EU have more limited access), the LDAP-to-RBAC sync implementation +can apply specializations based on whatever criteria it understands. + +### Example 3: Multi-cluster services + +Consider the same organization from previous examples. They have enabled an +implementation of multi-cluster Services, which lets them access backends which +are running on other clusters in the group. + +As in example 2, cluster-ops run a per-cluster metrics service, It does not +make sense for clients in cluster A to access the metrics server of cluster B. +Even though this runs in the same "metrics" namespace in both clusters (and +thus namespce sameness applies), the implementation of multi-cluster services +probably should not be on-by-default. The details of how multi-cluster +services will work are an area for innovation, but ideas include: + * Opt-in: services must be "exported" to be merged across clusters + * Opt-out: services or namespace can be opted out of service merging + * Different discovery: merged services and "raw" services use different names + or other discovery mechanisms + +However the implementation works, the metrics service is not automatically +merged across clusters, though the LDAP-to-RBAC sync from example 2 can still +apply consistent policies.