4.3.1 release notes.

Author: Jonathan S. Katz

docs/content/Configuration/configuration.md

@@ -12,7 +12,7 @@ The operator is template-driven; this makes it simple to configure both the clie
 
 The Operator is configured with a collection of files found in the *conf* directory.  These configuration files are deployed to your Kubernetes cluster when the Operator is deployed.  Changes made to any of these configuration files currently require a redeployment of the Operator on the Kubernetes cluster.
 
-The server components of the Operator include Role Based Access Control resources which need to be created a single time by a Kubernetes cluster-admin user.  See the Installation section for details on installing a Postgres Operator server.
+The server components of the Operator include Role Based Access Control resources which need to be created a single time by a privileged Kubernetes user.  See the Installation section for details on installing a Postgres Operator server.
 
 The configuration files used by the Operator are found in 2 places:
  * the pgo-config ConfigMap in the namespace the Operator is running in

docs/content/Security/install-postgres-operator-rbac.md

@@ -7,7 +7,9 @@ weight: 7
 
 ## Installation of PostgreSQL Operator RBAC
 
-Please note, installation of the PostgreSQL Operator RBAC requires Kubernetes Cluster-Admin.
+For a list of the RBAC required to install the PostgreSQL Operator, please view the [`postgres-operator.yml`](https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.3.1/installers/kubectl/postgres-operator.yml) file:
+
+[https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.3.1/installers/kubectl/postgres-operator.yml](https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.3.1/installers/kubectl/postgres-operator.yml)
 
 The first step is to install the PostgreSQL Operator RBAC configuration.  This can be accomplished  by running:
 

docs/content/architecture/namespace.md

@@ -97,7 +97,8 @@ Kubernetetes cluster, and then create and run and/or remove controllers as names
 updated and deleted.  However, while in this mode the Operator is unable to create, delete or
 update namespaces itself, nor can it create the RBAC it requires in any of those namespaces to
 create PostgreSQL clusters.  Therefore, while in a `readonly` mode namespaces must be
-pre-configured with the proper RBAC, since the Operator cannot create the RBAC itself.
+preconfigured with the proper RBAC, since the Operator cannot create the RBAC itself (unless
+it has permission to do so in its ServiceAccount, as described further on in this document).
 
 The following represents the `ClusterRole` required for the `readonly` mode to be enabled:
 

docs/content/installation/other/ansible/prerequisites.md

@@ -34,12 +34,11 @@ are required:
 
 ## Permissions
 
-The installation of the Crunchy PostgreSQL Operator requires elevated privileges.  
-It is required that the playbooks are run as a `cluster-admin` to ensure the playbooks
-can install:
+The installation of the Crunchy PostgreSQL Operator requires elevated
+privileges, as the following objects need to be created:
 
 * Custom Resource Definitions
-* Cluster RBAC
+* Cluster RBAC for using one of the multi-namespace modes
 * Create required namespaces
 
 {{% notice warning %}}In Kubernetes versions prior to 1.12 (including Openshift up through 3.11), there is a limitation that requires an extra step during installation for the operator to function properly with watched namespaces. This limitation does not exist when using Kubernetes 1.12+. When a list of namespaces are provided through the NAMESPACE environment variable, the setupnamespaces.sh script handles the limitation properly in both the bash and ansible installation.

docs/content/installation/other/bash.md

@@ -52,23 +52,10 @@ For various scripts used by the Operator, the *expenv* utility is required, down
 
 ## Default Installation - Namespace Creation
 
-The default installation will create 3 namespaces to use
-for deploying the Operator into and for holding Postgres clusters
-created by the Operator.
-
 Creating Kubernetes namespaces is typically something that only a
 privileged Kubernetes user can perform so log into your Kubernetes cluster as a user
 that has the necessary privileges.
 
-On Openshift if you do not want to install the Operator as the system
-administrator, you can grant cluster-admin privileges to a user
-as follows:
-
-    oc adm policy add-cluster-role-to-user cluster-admin pgoinstaller
-
-In the above command, you are granting cluster-admin privileges
-to a user named pgoinstaller.  
-
 The *NAMESPACE* environment variable is a comma separated list
 of namespaces that specify where the Operator will be provisioing
 PG clusters into, specifically, the namespaces the Operator is watching

docs/content/installation/postgres-operator.md

@@ -50,12 +50,14 @@ in the `postgres-operator.yml`, but can be updated based on your specific
 environmental requirements.
 
 By default, the `pgo-deployer` uses a ServiceAccount called `pgo-deployer-sa`
-that has a ClusterRoleBinding (`pgo-deployer-crb`) with the `cluster-admin`
-permission. This is required to create the [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+that has a ClusterRoleBinding (`pgo-deployer-crb`) with several ClusterRole
+permissions. This is required to create the [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 that power the PostgreSQL Operator. While the PostgreSQL Operator itself can be
 scoped to a specific namespace, you will need to have `cluster-admin` for the
 initial deployment, or privileges that allow you to install Custom Resource
-Definitions.
+Definitions. The required list of privileges are available in the [postgres-operator.yml](https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.3.1/installers/kubectl/postgres-operator.yml) file:
+
+[https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.3.1/installers/kubectl/postgres-operator.yml](https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.3.1/installers/kubectl/postgres-operator.yml)
 
 If you have already configured the ServiceAccount and ClusterRoleBinding for the
 installation process (e.g. from a previous installation), then you can remove

docs/content/releases/4.3.1.md

@@ -0,0 +1,93 @@
+---
+title: "4.3.1"
+date:
+draft: false
+weight: 95
+---
+
+Crunchy Data announces the release of the [PostgreSQL Operator](https://www.crunchydata.com/products/crunchy-postgresql-operator/) 4.3.1 on May 18, 2020.
+
+The PostgreSQL Operator is released in conjunction with the [Crunchy Container Suite](https://github.com/CrunchyData/crunchy-containers/).
+
+The PostgreSQL Operator 4.3.1 release includes the following software versions upgrades:
+
+- The PostgreSQL containers now use versions 12.3, 11.8, 10.13, 9.6.18, and 9.5.22
+
+PostgreSQL Operator is tested with Kubernetes 1.13 - 1.18, OpenShift 3.11+, OpenShift 4.3+, Google Kubernetes Engine (GKE), and VMware Enterprise PKS 1.3+.
+
+# Changes
+
+## Initial Support for SCRAM
+
+[SCRAM](https://info.crunchydata.com/blog/how-to-upgrade-postgresql-passwords-to-scram) is a password authentication method in PostgreSQL that has been available since PostgreSQL 10 and is considered to be superior to the `md5` authentication method. The PostgreSQL Operator now introduces support for SCRAM on the [`pgo create user`](https://access.crunchydata.com/documentation/postgres-operator/latest/pgo-client/reference/pgo_create_user/) and [`pgo update user`](https://access.crunchydata.com/documentation/postgres-operator/latest/pgo-client/reference/pgo_update_user/) commands by means of the `--password-type` flag. The following values for `--password-type` will select the following authentication methods:
+
+
+- `--password-type=""`, `--password-type="md5"` => md5
+- `--password-type="scram"`, `--password-type="scram-sha-256"` => SCRAM-SHA-256
+
+In turn, the PostgreSQL Operator will hash the passwords based on the chosen method and store the computed hash in PostgreSQL.
+
+When using SCRAM support, it is important to note the following observations and limitations:
+
+- When using one of the password modifications commands on `pgo update user` (e.g. `--password`, `--rotate-password`, `--expires`) with the desire to keep the persisted password using SCRAM, it is necessary to specify the "--password-type=scram-sha-256" directive.
+- SCRAM does not work with the current pgBouncer integration with the PostgreSQL Operator. pgBouncer presently supports only one password-based authentication type at a time. Additionally, to enable support for SCRAM, pgBouncer would require a list of plaintext passwords to be stored in a file that is accessible to it. Future work can evaluate how to leverage SCRAM support with pgBouncer.
+
+## `pgo restart` and `pgo reload`
+
+This release introduces the `pgo restart` command, which allow you to perform a PostgreSQL restart on one or more instances within a PostgreSQL cluster.
+
+You restart all instances at the same time using the following command:
+
+```shell
+pgo restart hippo
+```
+
+or specify a specific instance to restart using the `--target` flag (which follows a similar behavior to the `--target` flag on `pgo scaledown` and `pgo failover`):
+
+```shell
+pgo restart hippo --target=hippo-abcd
+```
+
+The restart itself is performed by calling the Patroni `restart` REST endpoint on the specific instance (primary or replica) being restarted.
+
+As with the `pgo failover` and `pgo scaledown` commands it is also possible to specify the `--query` flag to query instances available for restart:
+
+```shell
+pgo restart mycluster --query
+```
+
+With the new `pgo restart` command, using `--query` flag with the `pgo failover` and `pgo scaledown` commands include the `PENDING RESTART` information, which is now returned with any replication information.
+
+
+This release  allows for the `pgo reload` command to properly reloads all instances (i.e. the primary and all replicas) within the cluster.
+
+## Dynamic Namespace Mode and Older Kubernetes Versions
+
+The dynamic namespace mode (e.g. `pgo create namespace` + `pgo delete namespace`) provides the ability to create and remove Kubernetes namespaces and automatically add them unto the purview of the PostgreSQL Operator. Through the course of fixing usability issues with working with the other namespaces modes (`readonly`, `disabled`), a change needed to be introduced that broke compatibility with Kubernetes 1.12 and earlier.
+
+The PostgreSQL Operator still supports managing PostgreSQL Deployments across multiple namespaces in Kubernetes 1.12 and earlier, but only with `readonly` mode. In `readonly` mode, a cluster administrator needs to create the namespace and the RBAC needed to run the PostgreSQL Operator in that namespace. However, it is now possible to define the RBAC required for the PostgreSQL Operator to manage clusters in a namespace via a ServiceAccount, as described in the [Namespace](https://access.crunchydata.com/documentation/postgres-operator/latest/architecture/namespace/) section of the documentation.
+
+The usability change allows for one to add namespace to the PostgreSQL Operator's purview (or deploy the PostgreSQL Operator within a namespace) and automatically set up the appropriate RBAC for the PostgreSQL Operator to correctly operate.
+
+## Other Changes
+
+-  The RBAC required for deploying the PostgreSQL Operator is now decomposed into the exact privileges that are needed. This removes the need for requiring a `cluster-admin` privilege for deploying the PostgreSQL Operator. Reported by (@obeyler).
+- With namespace modes `disabled` and `readonly`, the PostgreSQL Operator will now dynamically create the required RBAC when a new namespace is added if that namespace has the RBAC defined in `local-namespace-rbac.yaml`. This occurs when `PGO_DYNAMIC_NAMESPACE` is set to `true`.
+- If the PostgreSQL Operator has permissions to manage it's own RBAC within a namespace, it will now reconcile and auto-heal that RBAC as needed (e.g. if it is invalid or has been removed) to ensure it can properly interact with and manage that namespace.
+- Add default CPU and memory limits for the metrics collection and pgBadger sidecars to help deployments that wish to have a Pod QoS of `Guaranteed`. The metrics defaults are 100m/24Mi and the pgBadger defaults are 500m/24Mi. Reported by (@jose-joye).
+- Introduce `DISABLE_FSGROUP` option as part of the installation. When set to `true`, this does not add a FSGroup to the Pod [Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) when deploying PostgreSQL related containers or pgAdmin 4. This is helpful when deploying the PostgreSQL Operator in certain environments, such as OpenShift with a `restricted` Security Context Constraint. Defaults to `false`.
+- Remove the custom Security Context Constraint (SCC) that would be deployed with the PostgreSQL Operator, so now the PostgreSQL Operator can be deployed using default OpenShift SCCs (e.g. "restricted", though note that `DISABLE_FSGROUP` will need to be set to `true` for that). The example PostgreSQL Operator SCC is left in the [`examples`](https://raw.githubusercontent.com/CrunchyData/postgres-operator/master/examples/pgo-scc.yaml) directory for reference.
+- When `PGO_DISABLE_TLS` is set to `true`, then `PGO_TLS_NO_VERIFY` is set to `true`.
+- Some of the `pgo-deployer` environmental variables that we not needed to be set by a user were internalized. These include `ANSIBLE_CONFIG` and `HOME`.
+- When using the `pgo-deployer` container to install the PostgreSQL Operator, update the default watched namespace to `pgo` as the example only uses this namespace.
+
+# Fixes
+- Fix for cloning a PostgreSQL cluster when the pgBackRest repository is stored in S3.
+- Ensure the `pgo-apiserver` will successfully run if `PGO_DISABLE_TLS` is set to `true`. Reported by (@zhubx007).
+- Prevent a run of `pgo-deployer` from failing if it detects the existence of dependent cluster-wide objects already present.
+- Deployments with `pgo-deployer` using the default file with `hostpathstorage` will now successfully deploy PostgreSQL clusters without any adjustments.
+- Ensure image pull secrets are attached to deployments of the `pgo-client` container.
+- Ensure `client-setup.sh` executes to completion if existing PostgreSQL Operator credentials exist that were created by a different installation method
+- Update the documentation to properly name `CCP_IMAGE_PULL_SECRET_MANIFEST` and `PGO_IMAGE_PULL_SECRET_MANIFEST` in the `pgo-deployer` configuration.
+- Several fixes for selecting default storage configurations and sizes when using the `pgo-deployer` container. These include #1, #4, and #8 in the `STORAGE` family of variables.
+- The custom setup example was updated to reflect the current state of bootstrapping the PostgreSQL container.