Skip to content

Commit 7cf2fae

Browse files
erthalionerthalion
authored
[WIP] Extend infrastructure roles handling (zalando#1064)
Extend infrastructure roles handling Postgres Operator uses infrastructure roles to provide access to a database for external users e.g. for monitoring purposes. Such infrastructure roles are expected to be present in the form of k8s secrets with the following content: inrole1: some_encrypted_role password1: some_encrypted_password user1: some_entrypted_name inrole2: some_encrypted_role password2: some_encrypted_password user2: some_entrypted_name The format of this content is implied implicitly and not flexible enough. In case if we do not have possibility to change the format of a secret we want to use in the Operator, we need to recreate it in this format. To address this lets make the format of secret content explicitly. The idea is to introduce a new configuration option for the Operator. infrastructure_roles_secrets: - secretname: k8s_secret_name userkey: some_encrypted_name passwordkey: some_encrypted_password rolekey: some_encrypted_role - secretname: k8s_secret_name userkey: some_encrypted_name passwordkey: some_encrypted_password rolekey: some_encrypted_role This would allow Operator to use any avalable secrets to prepare infrastructure roles. To make it backward compatible simulate the old behaviour if the new option is not present. The new configuration option is intended be used mainly from CRD, but it's also available via Operator ConfigMap in a limited fashion. For ConfigMap one can put there only a string with one secret definition in the following format (as a string): infrastructure_roles_secrets: | secretname: k8s_secret_name, userkey: some_encrypted_name, passwordkey: some_encrypted_password, rolekey: some_encrypted_role Note than only one secret could be specified this way, no multiple secrets are allowed. Eventually the resulting list of infrastructure roles would be a total sum of all supported ways to describe it, namely legacy via infrastructure_roles_secret_name and infrastructure_roles_secrets from both ConfigMap and CRD.
1 parent f3ddce8 commit 7cf2fae

20 files changed

+1366
-612
lines changed

‎charts/postgres-operator/crds/operatorconfigurations.yaml

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -131,6 +131,28 @@ spec:
131131
type: boolean
132132
infrastructure_roles_secret_name:
133133
type: string
134+
infrastructure_roles_secrets:
135+
type: array
136+
nullable: true
137+
items:
138+
type: object
139+
required:
140+
- secretname
141+
- userkey
142+
- passwordkey
143+
properties:
144+
secretname:
145+
type: string
146+
userkey:
147+
type: string
148+
passwordkey:
149+
type: string
150+
rolekey:
151+
type: string
152+
details:
153+
type: string
154+
template:
155+
type: boolean
134156
inherited_labels:
135157
type: array
136158
items:

‎docs/reference/operator_parameters.md

Lines changed: 8 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -252,8 +252,14 @@ configuration they are grouped under the `kubernetes` key.
252252
teams API. The default is `postgresql-operator`.
253253

254254
* **infrastructure_roles_secret_name**
255-
namespaced name of the secret containing infrastructure roles names and
256-
passwords.
255+
*deprecated*: namespaced name of the secret containing infrastructure roles
256+
with user names, passwords and role membership.
257+
258+
* **infrastructure_roles_secrets**
259+
array of infrastructure role definitions which reference existing secrets
260+
and specify the key names from which user name, password and role membership
261+
are extracted. For the ConfigMap this has to be a string which allows
262+
referencing only one infrastructure roles secret. The default is empty.
257263

258264
* **pod_role_label**
259265
name of the label assigned to the Postgres pods (and services/endpoints) by

‎docs/user.md

Lines changed: 50 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -150,23 +150,62 @@ user. There are two ways to define them:
150150

151151
#### Infrastructure roles secret
152152

153-
The infrastructure roles secret is specified by the `infrastructure_roles_secret_name`
154-
parameter. The role definition looks like this (values are base64 encoded):
153+
Infrastructure roles can be specified by the `infrastructure_roles_secrets`
154+
parameter where you can reference multiple existing secrets. Prior to `v1.6.0`
155+
the operator could only reference one secret with the
156+
`infrastructure_roles_secret_name` option. However, this secret could contain
157+
multiple roles using the same set of keys plus incrementing index.
155158

156159
```yaml
157-
user1: ZGJ1c2Vy
158-
password1: c2VjcmV0
159-
inrole1: b3BlcmF0b3I=
160+
apiVersion: v1
161+
kind: Secret
162+
metadata:
163+
name: postgresql-infrastructure-roles
164+
data:
165+
user1: ZGJ1c2Vy
166+
password1: c2VjcmV0
167+
inrole1: b3BlcmF0b3I=
168+
user2: ...
160169
```
161170
162171
The block above describes the infrastructure role 'dbuser' with password
163-
'secret' that is a member of the 'operator' role. For the following definitions
164-
one must increase the index, i.e. the next role will be defined as 'user2' and
165-
so on. The resulting role will automatically be a login role.
172+
'secret' that is a member of the 'operator' role. The resulting role will
173+
automatically be a login role.
174+
175+
With the new option users can configure the names of secret keys that contain
176+
the user name, password etc. The secret itself is referenced by the
177+
`secretname` key. If the secret uses a template for multiple roles as described
178+
above list them separately.
166179

167-
Note that with definitions that solely use the infrastructure roles secret
168-
there is no way to specify role options (like superuser or nologin) or role
169-
memberships. This is where the ConfigMap comes into play.
180+
```yaml
181+
apiVersion: v1
182+
kind: OperatorConfiguration
183+
metadata:
184+
name: postgresql-operator-configuration
185+
configuration:
186+
kubernetes:
187+
infrastructure_roles_secrets:
188+
- secretname: "postgresql-infrastructure-roles"
189+
userkey: "user1"
190+
passwordkey: "password1"
191+
rolekey: "inrole1"
192+
- secretname: "postgresql-infrastructure-roles"
193+
userkey: "user2"
194+
...
195+
```
196+
197+
Note, only the CRD-based configuration allows for referencing multiple secrets.
198+
As of now, the ConfigMap is restricted to either one or the existing template
199+
option with `infrastructure_roles_secret_name`. Please, refer to the example
200+
manifests to understand how `infrastructure_roles_secrets` has to be configured
201+
for the [configmap](../manifests/configmap.yaml) or [CRD configuration](../manifests/postgresql-operator-default-configuration.yaml).
202+
203+
If both `infrastructure_roles_secret_name` and `infrastructure_roles_secrets`
204+
are defined the operator will create roles for both of them. So make sure,
205+
they do not collide. Note also, that with definitions that solely use the
206+
infrastructure roles secret there is no way to specify role options (like
207+
superuser or nologin) or role memberships. This is where the additional
208+
ConfigMap comes into play.
170209

171210
#### Secret plus ConfigMap
172211

‎e2e/Dockerfile

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,10 @@
1+
# An image to perform the actual test. Do not forget to copy all necessary test
2+
# files here.
13
FROM ubuntu:18.04
24
LABEL maintainer="Team ACID @ Zalando <team-acid@zalando.de>"
35

46
COPY manifests ./manifests
7+
COPY exec.sh ./exec.sh
58
COPY requirements.txt tests ./
69

710
RUN apt-get update \

‎e2e/exec.sh

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
#!/usr/bin/env bash
2+
kubectl exec -it $1 -- sh -c "$2"

0 commit comments

Comments
 (0)