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

reflect some feedback

This commit is contained in:
Felix Kunde 2020-04-27 16:42:34 +02:00
parent e8a4495de4
commit 8bebd8107d
2 changed files with 22 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
docs/user.md
View File

@ -219,15 +219,16 @@ 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 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. this secret is configurable with the `oauth_token_secret_name` parameter.
## Prepared databases with best practice roles setup ## Prepared databases with roles and default privileges
The `users` section in the manifests only allows for creating database roles The `users` section in the manifests only allows for creating database roles
with global privileges. Fine-grained data access control or role membership can with global privileges. Fine-grained data access control or role membership can
not be defined and must be set up by the user in the database. But, the Postgres not be defined and must be set up by the user in the database. But, the Postgres
Operator offers a separate section to specify `preparedDatabases` that will be Operator offers a separate section to specify `preparedDatabases` that will be
bootstrapped with pre-defined owner, reader and writer roles on a database-level created with pre-defined owner, reader and writer roles for each individual
and, optionally, on a schema-level, too. `preparedDatabases` also enable users database and, optionally, for each database schema, too. `preparedDatabases`
to specify PostgreSQL extensions that shall be created in the bootstrap process. also enable users to specify PostgreSQL extensions that shall be created in a
given database schema.
### Default database and schema ### Default database and schema
@ -271,10 +272,14 @@ are configured for the owner role so that the `<dbname>_reader` role
automatically gets read-access (SELECT) to new tables and sequences and the automatically gets read-access (SELECT) to new tables and sequences and the
`<dbname>_writer` receives write-access (INSERT, UPDATE, DELETE on tables, `<dbname>_writer` receives write-access (INSERT, UPDATE, DELETE on tables,
USAGE and UPDATE on sequences). Both get USAGE on types and EXECUTE on USAGE and UPDATE on sequences). Both get USAGE on types and EXECUTE on
functions. The same principle applies on the schema level. Note, that the functions.
database-level roles will have access incl. default privileges on all database
schemas, too. If you don't need the dedicated schema roles - i.e. you only use The same principle applies for database schemas which are owned by the
one schema - you can disable the creation like this: `<dbname>_<schema>_owner` role. `<dbname>_<schema>_reader` is read-only,
`<dbname>_<schema>_writer` has write access and inherit reading from the reader
role. Note, that the `<dbname>_*` roles have access incl. default privileges on
all schemas, too. If you don't need the dedicated schema roles - i.e. you only
use one schema - you can disable the creation like this:
```yaml ```yaml
spec: spec:
@ -285,13 +290,15 @@ spec:
defaultRoles: false defaultRoles: false
``` ```
Then the schemas are owned by the database owner, too.
### Default LOGIN roles ### Default LOGIN roles
The roles described in the previous paragraph can be granted to LOGIN roles from The roles described in the previous paragraph can be granted to LOGIN roles from
the `users` section in the manifest. Optionally, the Postgres Operator can also the `users` section in the manifest. Optionally, the Postgres Operator can also
bootstrap default LOGIN roles for the database an each schema individually. create default LOGIN roles for the database an each schema individually. These
These roles will get the `_user` suffix and they inherit all right from their roles will get the `_user` suffix and they inherit all rights from their NOLOGIN
NOLOGIN counterparts. counterparts.
| Role name | Member of | Admin | | Role name | Member of | Admin |
| ------------------- | -------------- | ------------- | | ------------------- | -------------- | ------------- |
@ -316,8 +323,8 @@ spec:
### Database extensions ### Database extensions
Prepared databases also allow for creating Postgres extensions during bootstrap. Prepared databases also allow for creating Postgres extensions. They will be
They will be created by the database owner in the specified schema. created by the database owner in the specified schema.
```yaml ```yaml
spec: spec:

6
pkg/cluster/sync.go
View File

@ -548,10 +548,8 @@ func (c *Cluster) syncDatabases() error {
} }
// if no prepared databases are specified create a database named like the cluster // if no prepared databases are specified create a database named like the cluster
preparedDatabases := c.Spec.PreparedDatabases if c.Spec.PreparedDatabases != nil && len(c.Spec.PreparedDatabases) == 0 { // TODO: add option to disable creating such a default DB
if preparedDatabases == nil || len(preparedDatabases) == 0 { // TODO: add option to disable creating such a default DB c.Spec.PreparedDatabases = map[string]acidv1.PreparedDatabase{strings.Replace(c.Name, "-", "_", -1): {}}
preparedDatabases = map[string]acidv1.PreparedDatabase{strings.Replace(c.Name, "-", "_", -1): {}}
c.Spec.PreparedDatabases = preparedDatabases
} }
for preparedDatabaseName := range c.Spec.PreparedDatabases { for preparedDatabaseName := range c.Spec.PreparedDatabases {
_, exists := currentDatabases[preparedDatabaseName] _, exists := currentDatabases[preparedDatabaseName]