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.yamlis 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
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.
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: b.garcia@possibilit.nl
# 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-stagingClusterIssuer
kubectl apply -f 01-setting-issuers.yaml
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
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