Skip to content
logo
Percona Operator for PostgreSQL
Application and system users
Initializing search
    percona/k8spg-docs
    percona/k8spg-docs
    • Welcome
      • System Requirements
      • Design and architecture
      • Comparison with other solutions
      • Install on Minikube
      • Install on Google Kubernetes Engine (GKE)
      • Install with Helm
      • Generic Kubernetes installation
      • Install on OpenShift
      • Application and system users
        • System Users
          • YAML Object Format
        • Application users
      • Changing PostgreSQL Options
      • Anti-affinity and tolerations
      • Transport Encryption (TLS/SSL)
      • Telemetry
      • Backup and restore
      • Upgrade Percona Distribution for PostgreSQL and the Operator
      • Horizontal and vertical scaling
      • Monitor with Percona Monitoring and Management (PMM)
      • Restart or pause the cluster
      • Deploy a standby cluster for Disaster Recovery
      • Provide Percona Operator for PostgreSQL single-namespace and multi-namespace deployment
      • Use PostgreSQL tablespaces with Percona Operator for PostgreSQL
      • Custom Resource options
      • Operator installation options
      • Percona certified images
      • Frequently Asked Questions
      • Release notes index
      • Percona Operator for PostgreSQL 1.3.0 (2022-08-04)
      • Percona Operator for PostgreSQL 1.2.0 (2022-04-06)
      • Percona Operator for PostgreSQL 1.1.0 (2021-12-07)
      • Percona Operator for PostgreSQL 1.0.0 (2021-10-07)
      • Percona Operator for PostgreSQL 0.2.0 (2021-08-12)
      • Percona Operator for PostgreSQL 0.1.0 (2021-05-10)

    • System Users
      • YAML Object Format
    • Application users

    Users¶

    User accounts within the Cluster can be divided into two different groups:

    • application-level users: the unprivileged user accounts,
    • system-level users: the accounts needed to automate the cluster deployment and management tasks.

    System Users¶

    Credentials for system users are stored as a Kubernetes Secrets object. The Operator requires to be deployed before PostgreSQL Cluster is started. The name of the required secrets (cluster1-users by default) should be set in the spec.secretsName option of the deploy/cr.yaml configuration file.

    The following table shows system users’ names and purposes.

    Warning

    These users should not be used to run an application.

    The default PostgreSQL instance installation via the Percona Operator for PostgreSQL comes with the following users:

    Role name Attributes
    postgres Superuser, Create role, Create DB, Replication, Bypass RLS
    primaryuser Replication
    pguser Non-privileged user
    pgbouncer Administrative user for the pgBouncer connection pooler

    The postgres user will be the admin user for the database instance. The primaryuser is used for replication between primary and replicas. The pguser is the default non-privileged user (you can configure different name of this user in the spec.user Custom Resource option).

    YAML Object Format¶

    The default name of the Secrets object for these users is cluster1-users and can be set in the CR for your cluster in spec.secretName to something different. When you create the object yourself, it should match the following simple format:

    apiVersion: v1
    kind: Secret
    metadata:
      name: cluster1-users
    type: Opaque
    stringData:
      pgbouncer: pgbouncer_password
      postgres: postgres_password
      primaryuser: primaryuser_password
     pguser: pguser_password
    

    The example above matches what is shipped in the deploy/secrets.yaml file.

    As you can see, we use the stringData type when creating the Secrets object, so all values for each key/value pair are stated in plain text format convenient from the user’s point of view. But the resulting Secrets object contains passwords stored as data - i.e., base64-encoded strings. If you want to update any field, you’ll need to encode the value into base64 format. To do this, you can run echo -n "password" | base64 --wrap=0 (or just echo -n "password" | base64 in case of Apple macOS) in your local shell to get valid values. For example, setting the PMM Server user’s password to new_password in the cluster1-users object can be done with the following command:

    $ kubectl patch secret/cluster1-users -p '{"data":{"pguser": "'$(echo -n new_password | base64 --wrap=0)'"}}'
    
    $ kubectl patch secret/cluster1-users -p '{"data":{"pguser": "'$(echo -n new_password | base64)'"}}'
    

    Application users¶

    By default you can connect to PostgreSQL as non-privileged pguser user. Also, you can login as postgres (the superuser) to PostgreSQL Pods, but pgBouncer (the connection pooler for PostgreSQL) doesn’t allow postgres user access by default. That’s done for security reasons.

    If you still need to provide postgres user access to PostgreSQL instances from the outside, set the pgBouncer.exposePostgresUser option in the deploy/cr.yaml configuration file to true and apply changes as usual by the kubectl apply -f deploy/cr.yaml command.

    Note

    Allowing superusers to access to the cluster is not recommended.

    Contact Us

    For free technical help, visit the Percona Community Forum.

    To report bugs or submit feature requests, open a JIRA ticket.

    For paid support and managed or consulting services , contact Percona Sales.


    Last update: 2023-02-09
    Back to top
    Percona LLC and/or its affiliates, © 2009 - 2022
    Made with Material for MkDocs

    Cookie consent

    We use cookies to recognize your repeated visits and preferences, as well as to measure the effectiveness of our documentation and whether users find what they're searching for. With your consent, you're helping us to make our documentation better.