How to install cert-manager and start to work with kong

Using cert-manager to work with kong and ingress

cert-manager is a native Kubernetes certificate management controller. It can help with issuing certificates from a variety of sources, such as Let’s Encrypt, HashiCorp Vault, a simple signing keypair, or self signed.

We are going to use Let's Encrypt to issue our zcrm365 certificate

Install the cert-manager CustomResourceDefinition resources separately 00-crds.yaml is here https://cert-manager.readthedocs.io/en/latest/getting-started/install.html#steps

⟩ kubectl apply -f 00-crds.yaml 
customresourcedefinition.apiextensions.k8s.io/certificates.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/issuers.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/clusterissuers.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/orders.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/challenges.certmanager.k8s.io unchanged
[I] 
~/workspace/ZCRM365/Deployments/Kubernetes/cert-manager · (Deployments±)
⟩

Create the namespace for cert-manager

⟩ kubectl create namespace cert-manager
namespace/cert-manager created
[I]

Disabling resource validation - https://cert-manager.readthedocs.io/en/latest/getting-started/install.html#installing-with-regular-manifests

Label the cert-manager namespace to disable resource validation

⟩ kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true
  
namespace/cert-manager labeled
[I]

Read about this, and document resource validation and webhook hjow to can works here. https://cert-manager.readthedocs.io/en/latest/getting-started/webhook.html

1. Installing cert-manager from helm chart

We are going to install helm cert manager form chart repository, this is the chart. For the moment we are going to install using helm. We don't need download the chart.

⟩ helm install --name cert-manager --namespace cert-manager stable/cert-manager
NAME:   cert-manager
LAST DEPLOYED: Mon Mar  4 14:42:21 2019
NAMESPACE: cert-manager
STATUS: DEPLOYED

RESOURCES:
==> v1alpha1/Issuer
NAME                           AGE
cert-manager-webhook-selfsign  1s
cert-manager-webhook-ca        1s

==> v1/ConfigMap
NAME                          DATA  AGE
cert-manager-webhook-ca-sync  1     2s

==> v1beta1/RoleBinding
NAME                                                AGE
cert-manager-webhook:webhook-authentication-reader  1s

==> v1beta1/Deployment
NAME                  DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
cert-manager-webhook  1        1        1           0          1s
cert-manager          1        1        1           0          1s

==> v1beta1/CronJob
NAME                          SCHEDULE  SUSPEND  ACTIVE  LAST SCHEDULE  AGE
cert-manager-webhook-ca-sync  @weekly   False    0       <none>         1s

==> v1/Job
NAME                          COMPLETIONS  DURATION  AGE
cert-manager-webhook-ca-sync  0/1          1s        1s

==> v1/Pod(related)
NAME                                  READY  STATUS             RESTARTS  AGE
cert-manager-webhook-85dd96d87-llvqr  0/1    ContainerCreating  0         1s
cert-manager-5f8db6f6c4-tjkmg         0/1    ContainerCreating  0         1s
cert-manager-webhook-ca-sync-ncx88    0/1    ContainerCreating  0         1s

==> v1beta1/ClusterRole
NAME                          AGE
cert-manager-webhook-ca-sync  2s
cert-manager                  2s

==> v1beta1/ClusterRoleBinding
NAME                                 AGE
cert-manager-webhook-ca-sync         2s
cert-manager-webhook:auth-delegator  2s
cert-manager                         1s

==> v1/Service
NAME                  TYPE       CLUSTER-IP    EXTERNAL-IP  PORT(S)  AGE
cert-manager-webhook  ClusterIP  10.0.147.194  <none>       443/TCP  1s

==> v1alpha1/Certificate
NAME                              AGE
cert-manager-webhook-ca           1s
cert-manager-webhook-webhook-tls  1s

==> v1/ServiceAccount
NAME                          SECRETS  AGE
cert-manager-webhook-ca-sync  1        2s
cert-manager-webhook          1        2s
cert-manager                  1        2s

==> v1/ClusterRole
NAME                                    AGE
cert-manager-webhook:webhook-requester  2s
cert-manager-edit                       2s
cert-manager-view                       2s

==> v1beta1/APIService
NAME                                  AGE
v1beta1.admission.certmanager.k8s.io  1s

==> v1beta1/ValidatingWebhookConfiguration
NAME                  AGE
cert-manager-webhook  1s


NOTES:
cert-manager has been deployed successfully!

In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).

More information on the different types of issuers and how to configure them
can be found in our documentation:

https://cert-manager.readthedocs.io/en/latest/reference/issuers.html

For information on how to configure cert-manager to automatically provision
Certificates for Ingress resources, take a look at the `ingress-shim`
documentation:

https://cert-manager.readthedocs.io/en/latest/reference/ingress-shim.html

[I]

We can see that the helm cert-manager chart came with their own issuers and certificates, is possible that I should use them to point to them my request certificates and not to my own Issuer and certificates.

2. Configuring Issuer/ClusterIssuer

Issuer/ClusterIssuer represent a certificate authority from which signed x509 certificates can be obtained, such as Let’s Encrypt, or your own signing key pair stored in a Kubernetes Secret resource. They are referenced by Certificate resources in order to request certificates from them.

An Issuer is scoped to a single namespace, and can only fulfill Certificate resources within its own namespace. This is useful in a multi-tenant environment where multiple teams or independent parties operate within a single cluster.

On the other hand, a ClusterIssuer is a cluster wide version of an Issuer. It is able to be referenced by Certificate resources in any namespace.

Users often create letsencrypt-staging and letsencrypt-prod ClusterIssuers if they operate a single-tenant environment and want to expose a cluster-wide mechanism for obtaining TLS certificates from Let’s Encrypt.

Let's encrypt recommend initially use the staging server environment

In addition we are going to use a ClusterIssuer in order to attend any certificate request of any namespace inside our AKS cluster. We are going to create our ClusterIssuer


apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    # The ACME server URL
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    # You must replace this email address with your own.
    # Let's Encrypt will use this to contact you about expiring
    # certificates, and issues related to your account.
    email: [email protected]
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      # This secret already exist with cert-manager 
      name: letsencrypt-staging
    # Enable the HTTP-01 challenge provider
    http01: {}

Creating the letsencrypt-staging ClusterIssuer

kubectl apply -f 01-setting-issuers.yaml

3. Request to certificate to our cluster issuer

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: zcrm365-test1
  namespace: default
spec:
  secretName: zcrm365-test1-tls
  # duration: 2160h # 90d
  renewBefore: 360h # 15d
  commonName: test1kongletsencrypt.possibilit.nl
  dnsNames:
  - test1kongletsencrypt.possibilit.nl
  #- www.test1kongletsencrypt.possibilit.nl
  issuerRef:
    name: letsencrypt-staging
    # We can reference ClusterIssuers by changing the kind here.
    # The default value is Issuer (i.e. a locally namespaced Issuer)
    kind: ClusterIssuer
  acme:
    config:
    - http01:
        ingressClass: nginx # Very important value
      domains:
      - test1kongletsencrypt.possibilit.nl

Poner que es necesario aplicar the nginx class which is the class of our ingress ... docyentar estio

⟩ kubectl apply -f 02-certificate-resource.yaml

4. Creating the ingress and creating their certificate

https://cert-manager.readthedocs.io/en/latest/tasks/issuing-certificates/ingress-shim.html#configuration

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kong-ingress-zcrm365
  namespace: default
  annotations:
    # nginx.ingress.kubernetes.io/ingress.class: "nginx"
    # certmanager.k8s.io/issuer: "letsencrypt-staging"
    # add an annotation indicating the issuer to use.
    certmanager.k8s.io/cluster-issuer: letsencrypt-staging
    certmanager.k8s.io/acme-challenge-type: http01
spec:
  rules: 
  - host: test1kongletsencrypt.possibilit.nl
    http:
      paths:
      - backend:
          serviceName: zcrm365dev
          servicePort: 80
        path: /
        
  tls: # < placing a host in the TLS config will indicate a cert should be created
  - hosts: 
    - test1kongletsencrypt.possibilit.nl
    secretName: zcrm365ingress-cert # < cert-manager will store the created certificate in this secret.


  # Important to read and explore
  # https://cert-manager.readthedocs.io/en/latest/tasks/issuing-certificates/ingress-shim.html#configuration

⟩ kubectl apply -f 03-zcrm365-ingress.yaml

These ingress are going to take our kong-proxy ip address configured in the dns name

look special fields to acme issuer look webhook validations look other things

bgarcial/README.md

Using cert-manager to work with kong and ingress

1. Installing cert-manager from helm chart

2. Configuring Issuer/ClusterIssuer

3. Request to certificate to our cluster issuer

4. Creating the ingress and creating their certificate