It's a common requirement to expose applications, either publicly or internally, with secure, TLS-encrypted endpoints.
Web applications should use HTTPS endpoints, and it's a strong security recommendation to use end-to-end encryption for internal communication between your applications and services.
Kore automatically installs and configures the cert-manager application in each managed Kubernetes cluster, which creates and manages X.509 certificates (used by TLS) for Kubernetes Ingress objects and other requirements.
This topic gives instructions for configuring cert-manager and creating a self-signed certificate.
cert-manager builds on top of Kubernetes, introducing certificate authorities and certificates as first-class resource types in the Kubernetes API. This makes it possible to provide 'certificates as a service' to developers working within a Kubernetes cluster.
If you would like to learn more, please visit cert-manager.io.
To configure cert-manager in the UI:
On the team page, navigate to Settings > TLS certificates, and then configure certificate management.
Your settings are stored in a ConfigMap object called
To configure cert-manager with the CLI:
Configure cert-manager using the optional ConfigMap object called
certificates-configuration, as shown in the Example below.
certificates-configuration.yaml:apiVersion: v1kind: ConfigMapmetadata:name: certificates-configurationnamespace: myteamdata:email: <shared team email address>
Available config parameters:
- data.email: Let's Encrypt sends certificate expiration (and other account-related) notices to this email address
Update the ConfigMap using the
kore applycommand:$ kore apply -t myteam -f certificates-configuration.yaml
In order to issue certificates, cert-manager requires configuration of Issuer or ClusterIssuer objects for each certificate provider. An Issuer can only be used in the namespace where it was created, but ClusterIssuers can be used in any namespace.
Kore automatically installs the following ClusterIssuers in a cluster.
|prod-le-dns01||Recommended. Generation normally takes 1-2 minutes. Uses Let's Encrypt to issue TLS certificates for HTTPS endpoints. Domain ownership is validated by cert-manager creating a TXT record on the domain for which a certificate is created.|
|prod-le-http01||Generation normally takes 5-6 minutes. Let's Encrypt to issue TLS certificates for HTTPS endpoints. Domain ownership is validated by cert-manager creating a temporary HTTP application that serves the required validation information on a specific path on the domain for which a certificate is created. |
This validation can only be used if there is an ingress controller called
|self-signed||Can be used to generate self-signed certificates in the cluster. Self-signed certificates are commonly used for encrypting internal traffic between the application and the ingress controller.|
In this example, you will create a self-signed certificate for end-to-end (mTLS) encryption.
To create a self-signed certificate:
Certificateobject, as shown in the example below.
certificate.yaml:apiVersion: cert-manager.io/v1kind: Certificatemetadata:name: myapp-certnamespace: mynamespacespec:secretName: myapp-certduration: 2160hrenewBefore: 720hissuerRef:kind: ClusterIssuername: self-signedcommonName: myapp.mynamespace.svc.cluster.localisCA: true
Run this command to apply the
certificate.yaml:$ kubectl -n mynamespace apply -f certificate.yaml
To check the status of the certificate:
Run the following for your namespace:$ kubectl -n mynamespace get certificateNAME READY SECRET AGEmyapp-cert True myapp-cert 56s
If the certificate is ready, the requested certificate data will be saved in the
myapp-certsecret:$ kubectl -n mynamespace get secret myapp-cert -o yamlapiVersion: v1kind: Secretmetadata:name: myapp-certnamespace: test[...]type: kubernetes.io/tlsdata:ca.crt: <base64-encrypted CA certificate>tls.crt: <base64-encrypted certificate>tls.key: <certificate private key>
For information on using the generated certificate in your application, see the Kubernetes Secrets documentation.