public_git
/
postgres-operator
mirror of https://github.com/zalando/postgres-operator.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

update docs

This commit is contained in:
Felix Kunde 2022-01-21 19:48:10 +01:00
parent 73b4e3ac92
commit f5e96c8aa5
2 changed files with 39 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
docs/administrator.md
View File

@ -298,27 +298,33 @@ For Helm deployments setting `rbac.createAggregateClusterRoles: true` adds these
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:
default users from `preparedDatabases`, system users). Furthermore, there
are the following exceptions:
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.
3. Database owners and direct members of owners, since ownership on database objects 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
are replaced in the K8s 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.
inherited meaning that migration scripts should still grant and revoke rights
against the original role. The timestamp of the next rotation is written to the
secret as well. Note, if the rotation interval is decreased it is reflected in
the secrets only if the next rotation date is more days away than the new
length of the interval.
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.
Pods still using the previous secret values which they keep 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 roles created by
the password rotation feature 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. When
the creation date of a rotated user is older than the retention period it
might not get removed immediately. Only on the next user rotation it is checked
if users can get removed. Therefore, you might want to configure the retention
to be a multiple of the rotation interval.
### Password rotation for single roles
@ -350,8 +356,19 @@ spec:
```
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.
owners, but only if they are not used as application users for regular read
and write operations.
### Turning off password rotation
When password rotation is turned off again the operator will check if the
`username` value in the secret matches the original username and replace it
with the latter. A new password is assigned and the `nextRotation` field is
cleared. A final lookup for child (rotation) users to be removed is done but
they will only be dropped if the retention policy allows for it. This is to
avoid sudden connection issues in pods which still use credentials of these
users in memory. You have to remove these child roles manually or re-enable
password rotation with smaller interval so they get cleaned up.
## Use taints and tolerations for dedicated PostgreSQL nodes

7
pkg/cluster/sync.go
View File

@ -673,6 +673,13 @@ func (c *Cluster) syncSecrets() error {
updateSecretMsg = fmt.Sprintf("rotation date not found in secret %q. Setting it to %s", secretSpec.Name, nextRotationDateStr)
}
// check if next rotation can happen sooner
// if rotation interval has been decreased
currentRotationDate, _ := c.getNextRotationDate(currentTime)
if nextRotationDate.After(currentRotationDate) {
nextRotationDate = currentRotationDate
}
// update password and next rotation date if configured interval has passed
if currentTime.After(nextRotationDate) {
// create rotation user if role is not listed for in-place password update