merge master

docs/administrator.md

@@ -561,9 +561,12 @@ database.
 * **Human users** originate from the [Teams API](user.md#teams-api-roles) that
 returns a list of the team members given a team id. The operator differentiates
 between (a) product teams that own a particular Postgres cluster and are granted
-admin rights to maintain it, and (b) Postgres superuser teams that get the
-superuser access to all Postgres databases running in a K8s cluster for the
-purposes of maintaining and troubleshooting.
+admin rights to maintain it, (b) Postgres superuser teams that get superuser
+access to all Postgres databases running in a K8s cluster for the purposes of
+maintaining and troubleshooting, and (c) additional teams, superuser teams or
+members associated with the owning team. The latter is managed via the
+[PostgresTeam CRD](user.md#additional-teams-and-members-per-cluster).
+
 
 ## Understanding rolling update of Spilo pods
 

docs/reference/operator_parameters.md

@@ -598,8 +598,8 @@ key.
   The default is `"log_statement:all"`
 
 * **enable_team_superuser**
-  whether to grant superuser to team members created from the Teams API.
-  The default is `false`.
+  whether to grant superuser to members of the cluster's owning team created
+  from the Teams API. The default is `false`.
 
 * **team_admin_role**
   role name to grant to team members created from the Teams API. The default is
@@ -632,6 +632,16 @@ key.
   cluster to administer Postgres and maintain infrastructure built around it.
   The default is empty.
 
+* **enable_postgres_team_crd**
+  toggle to make the operator watch for created or updated `PostgresTeam` CRDs
+  and create roles for specified additional teams and members.
+  The default is `false`.
+
+* **enable_postgres_team_crd_superusers**
+  in a `PostgresTeam` CRD additional superuser teams can assigned to teams that
+  own clusters. With this flag set to `false`, it will be ignored.
+  The default is `false`.
+
 ## Logging and REST API
 
 Parameters affecting logging and REST API listener. In the CRD-based

docs/user.md

@@ -269,6 +269,72 @@ to choose superusers, group roles, [PAM configuration](https://github.com/CyberD
 etc. An OAuth2 token can be passed to the Teams API via a secret. The name for
 this secret is configurable with the `oauth_token_secret_name` parameter.
 
+### Additional teams and members per cluster
+
+Postgres clusters are associated with one team by providing the `teamID` in
+the manifest. Additional superuser teams can be configured as mentioned in
+the previous paragraph. However, this is a global setting. To assign
+additional teams, superuser teams and single users to clusters of a given
+team, use the [PostgresTeam CRD](../manifests/postgresteam.yaml). It provides
+a simple mapping structure.
+
+
+```yaml
+apiVersion: "acid.zalan.do/v1"
+kind: PostgresTeam
+metadata:
+  name: custom-team-membership
+spec:
+  additionalSuperuserTeams:
+    acid:
+    - "postgres_superusers"
+  additionalTeams:
+    acid: []
+  additionalMembers:
+    acid:
+    - "elephant"
+```
+
+One `PostgresTeam` resource could contain mappings of multiple teams but you
+can choose to create separate CRDs, alternatively. On each CRD creation or
+update the operator will gather all mappings to create additional human users
+in databases the next time they are synced. Additional teams are resolved
+transitively, meaning you will also add users for their `additionalTeams`
+or (not and) `additionalSuperuserTeams`.
+
+For each additional team the Teams API would be queried. Additional members
+will be added either way. There can be "virtual teams" that do not exists in
+your Teams API but users of associated teams as well as members will get
+created. With `PostgresTeams` it's also easy to cover team name changes. Just
+add the mapping between old and new team name and the rest can stay the same.
+
+```yaml
+apiVersion: "acid.zalan.do/v1"
+kind: PostgresTeam
+metadata:
+  name: virtualteam-membership
+spec:
+  additionalSuperuserTeams:
+    acid:
+    - "virtual_superusers"
+    virtual_superusers:
+    - "real_teamA"
+    - "real_teamB"
+    real_teamA:
+    - "real_teamA_renamed"
+  additionalTeams:
+    real_teamA:
+    - "real_teamA_renamed"
+  additionalMembers:
+    virtual_superusers:
+    - "foo"
+```
+
+Note, by default the `PostgresTeam` support is disabled in the configuration.
+Switch `enable_postgres_team_crd` flag to `true` and the operator will start to
+watch for this CRD. Make sure, the cluster role is up to date and contains a
+section for [PostgresTeam](../manifests/operator-service-account-rbac.yaml#L30).
+
 ## Prepared databases with roles and default privileges
 
 The `users` section in the manifests only allows for creating database roles