Merge branch 'master' into major-version-upgrade

docs/administrator.md

@@ -559,9 +559,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/command_line_and_environment.md

@@ -56,3 +56,7 @@ The following environment variables are accepted by the operator:
 * **CRD_READY_WAIT_INTERVAL**
   defines the  interval between consecutive attempts waiting for the
   `postgresql` CRD to be created. The default is 5s.
+  
+* **ENABLE_JSON_LOGGING**
+  Set to `true` for JSON formatted logging output.
+  The default is false.

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

@@ -49,7 +49,7 @@ Note, that the name of the cluster must start with the `teamId` and `-`. At
 Zalando we use team IDs (nicknames) to lower the chance of duplicate cluster
 names and colliding entities. The team ID would also be used to query an API to
 get all members of a team and create [database roles](#teams-api-roles) for
-them.
+them. Besides, the maximum cluster name length is 53 characters.
 
 ## Watch pods being created
 
@@ -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