# Optional: allow a DBA to read ONE named application credential Secret.
#
# This is a namespaced Role rather than a ClusterRole because `resourceNames`
# is specific to a namespace. Never list the `<cluster>-superuser` Secret or
# any CA or replication Secret here.
#
# Granting `list` or `watch` on Secrets would expose the content of every
# Secret in the namespace, so only `get` is granted. Because the names are
# fixed, this Role must be updated when the Cluster is created or deleted.
# Environments that automate the Cluster lifecycle may prefer to grant no
# Secret access at all and obtain credentials through their own tooling.
#
# For a Cluster named `cluster-example` bootstrapped with `initdb`, the
# application credentials are in the `cluster-example-app` Secret.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cnpg-dba-app-secret
  namespace: default
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]
    resourceNames: ["cluster-example-app"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cnpg-dba-app-secret
  namespace: default
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: dbas
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: cnpg-dba-app-secret