public_git/postgres-operator
1
0
Fork 0
mirror of https://github.com/zalando/postgres-operator.git synced 2026-10-04 22:59:50 +02:00
Code Issues Projects Releases Wiki Activity

add user retention

Browse Source
This commit is contained in:
Felix Kunde
2022-01-21 17:46:06 +01:00
parent ab9aff3775
commit 08542711e0
16 changed files with 4110 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/administrator.md
+56
View File
@@ -293,6 +293,62 @@ that are aggregated into the K8s [default roles](https://kubernetes.io/docs/refe
For Helm deployments setting `rbac.createAggregateClusterRoles: true` adds these clusterroles to the deployment.
## Password rotation in K8s secrets
The operator regularly updates credentials in the K8s secrets if the
`enable_password_rotation` option is set to `true` in the configuration.
It happens only for LOGIN roles with an associated secret (manifest roles,
default user from `preparedDatabases`, system users). Furthermore, there
the following roles are excluded:
1. Infrastructure role secrets since rotation should happen by the infrastructure.
2. Team API roles that connect via OAuth2 and JWT token. Rotation should be provided by the infrastructure + there is even no secret for these roles
3. Database owners and members of owners, since ownership can not be inherited.
The interval of days can be set with `password_rotation_interval` (default
`90` = 90 days, minimum 1). On each rotation the user name and password values
are replaced in the secret. They belong to a newly created user named after
the original role plus rotation date in YYMMDD format. All priviliges are
inherited meaning that migration scripts continue to apply grants/revokes
against the original role. The timestamp of the next rotation is written to
the secret as well.
Pods still using the previous secret values in memory continue to connect to
the database since the password of the corresponding user is not replaced.
However, a retention policy can be configured for created roles by password
rotation with `password_rotation_user_retention`. The operator will ensure
that this period is at least twice as long as the configured rotation
interval, hence the default of `180` = 180 days.
### Password rotation for single roles
From the configuration, password rotation is enabled for all secrets with the
mentioned exceptions. If you wish to first test rotation for a single user (or
just have it enabled only for a few secrets) you can specify it in the cluster
manifest. The rotation and retention intervals can only be configured globally.
```
spec:
usersWithSecretRotation: "foo_user,bar_reader_user"
```
### Password replacement without extra roles
For some use cases where the secret is only used rarely - think of a `flyway`
user running a migration script on pod start - we do not need to create extra
database roles but can replace only the password in the K8s secret. This type
of rotation cannot be configured globally but specified in the cluster
manifest:
```
spec:
usersWithInPlaceSecretRotation: "flyway,bar_owner_user"
```
This would be the recommended option to enable rotation in secrets of database
owners, But only if they are not used as application users for regular read
and write operation.
## Use taints and tolerations for dedicated PostgreSQL nodes
To ensure Postgres pods are running on nodes without any other application pods,
docs/reference/operator_parameters.md
+22
View File
@@ -174,6 +174,28 @@ under the `users` key.
Postgres username used for replication between instances. The default is
`standby`.
* **enable_password_rotation**
For all LOGIN roles that are not database owners the Operator can rotate
credentials in the corresponding K8s secrets by replacing the username and
password. This means, new users will be added on each rotation inheriting
all priviliges from the original roles. The rotation date in the YYMMDD is
appended to the new user names. The timestamp of the next rotation is
written to the secret. The default is `false`.
* **password_rotation_interval**
If password rotation is enabled (either from config or cluster manifest) the
interval can be configured with this parameter. The measure is in days which
means daily rotation (`1`) is the most frequent interval possible.
Default is `90`.
* **password_rotation_user_retention**
To avoid an ever growing amount of new users due to password rotation the
operator will remove the created users again after a certain amount of days
has passed. The number can be configured with this parameter. However, the
operator will check that the retention policy is at least twice as long as
the rotation interval and update to this minimum in case it is not.
Default is `180`.
## Major version upgrades
Parameters configuring automatic major version upgrades. In a