Add example using cert-manager

# Using Cert-Manager with Postgres Operator 5.x

## Introduction

Starting with version 5.0 of the Crunchy Data Postgres Operator for Kubernetes, TLS is on by default to secure all communication to/from the postgres cluster.  By default, the Operator will generate the necessary certificates for the Postgres cluster and components.  It is possible to provide custom cetificates by storing the certificates in a Kubernetes Secret and pointing the Operator to those secrets in the Postgres manifest.

Cert-Manager can be used to dynamically generate and manage certificates in Kubernetes.   Cert-Manager can generate self-signed certificates or certificates from several certificate authorities.

This example shows how to use custom self-signed certificates generated by Cert-Manager.

## Cert-Manager Installation

The first step is to deploy Cert-Manager to the Kubernetes cluster.  To do this, follow the instructions on the Cert-Manager website (https://cert-manager.io/docs/installation/).

## Setup Certificate Issuer

After Cert-Manager has been deployed, the next step used in this example is to setup a Certificate Issuer.  The Certificate Issuer can be configured to be local to a namespace or cluster wide.  In the examples provided here, a cluster wide issuer is created.

### Configure Issuer

```kubectl apply -k certman```

This Kustomize deployment performs the following actions:

* Creates a cluster wide (ClusterIssuer) self-signed certificate issuer.

* Generates a common CA certificate.

* Creates a cluster wide (ClusterIssuer) CA certificate issuer using the generated CA certificate.

By default the issues are created in the cert-manager namespace which is the default namespace for Cert-Manager.

The CA certificate issuer is important as the Postgres components require that the ca.crt be the same for the certificates generated to support Postgres.

## Deploy Postgres with Custom Certificates

With the cluster wide certificate issuer in place, the next step is to generate certificates and then instruct the Operator to use these certicates.

Two certificates will be generated by the Kustomize deployment.  The first certificate secret is named <cluster>-tls (hippo-tls in this example) and the second certificate <cluster>-repl-tls (hippo-repl-tls).  The critical different between the two certificates is the Common Name (CN).  For the replication certificate (<cluster>-repl-tls), the Common Name must be _crunchyrepl.  If the Common Name is not set properly then the replicas will fail doing bootstrap process.

In the Postgres manifest, two entries are added to point to the newly created Secrets.  The customTLSSecret key references the <cluster>-tls secret while the customReplicationTLSSecret references the <cluster>-repl-tls secret.

### Deploy Postgres Cluster

```kubectl apply -k postgres```

The following process takes place during the deployment:

* Custom certificate is generated for Postgres using the CA ClusterIssuer created in the previous steps.

* Custom certificate is generated for Postgres replication using the CA ClusterIssuer.

* Postgres cluster deployed using the custom certificates.

---

apiVersion: cert-manager.io/v1

kind: Certificate

metadata:

  name: selfsigned-ca

  namespace: cert-manager

spec:

  isCA: true

  commonName: postgres-operator

  secretName: root-secret

  privateKey:

    algorithm: ECDSA

    size: 256

  issuerRef:

    name: selfsigned-cluster-issuer

    kind: ClusterIssuer

    group: cert-manager.io

 No newline at end of file

---

apiVersion: cert-manager.io/v1

kind: ClusterIssuer

metadata:

  name: ca-issuer

  namespace: cert-manager

spec:

  ca:

    secretName: root-secret

resources:

- selfsigned-clusterissuer.yaml

- ca-cert.yaml

- ca-issuer.yaml

---

apiVersion: cert-manager.io/v1

kind: ClusterIssuer

metadata:

  name: selfsigned-cluster-issuer

  namespace: cert-manager

spec:

  selfSigned: {}