You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: How to deploy a centralized SSL certification management solution based on Cert-manager in our Raspberry Pi Kuberentes cluster.
5
-
last_modified_at: "25-02-2022"
5
+
last_modified_at: "08-03-2022"
6
6
---
7
7
8
8
In the Kubernetes cluster, [Cert-Manager](https://cert-manager.io/docs/) can be used to automate the certificate management tasks (issue certificate request, renewals, etc.). Cert-manager adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates.
9
9
10
-
It can issue certificates from a variety of supported sources, including support for auto-signed certificates or use [Let's Encrypt](https://letsencrypt.org/) service to obtain validated SSL certificates. It will ensure certificates are valid and up to date, and attempt to renew certificates at a configured time before expiry.
10
+
It can issue certificates from a variety of supported sources, including support for auto-signed certificates or use [Let's Encrypt](https://letsencrypt.org/) service to obtain validated SSL certificates. It will ensure certificates are valid and up to date, and attempt to renew certificates at a configured time before expiry. It also keep up to date the associated Kuberentes Secrets storing key pairs used by Ingress resources when securing the incoming communications.
11
11
12
-
{{site.data.alerts.note}}
13
-
CertManager integration with Let's Encryp has not been configured since my DNS provider does not suppport yet the API for automating DNS challenges. See open issue [#16](https://github.com/ricsanfre/pi-cluster/issues/16).
In cert-manager different kind of certificate issuer can be configured to generate signed SSL certificates
17
+
18
+
### Self-signed Issuer
19
+
20
+
The SelfSigned issuer doesn’t represent a certificate authority as such, but instead denotes that certificates will “sign themselves” using a given private key. In other words, the private key of the certificate will be used to sign the certificate itself.
21
+
22
+
This Issuer type is useful for bootstrapping a root certificate (CA) for a custom PKI (Public Key Infrastructure).
23
+
24
+
We will use this Issuer for bootstrapping our custom CA.
25
+
26
+
### CA Issuer
27
+
28
+
The CA issuer represents a Certificate Authority whereby its certificate and private key are stored inside the cluster as a Kubernetes Secret, and will be used to sign incoming certificate requests. This internal CA certificate can then be used to trust resulting signed certificates.
29
+
30
+
This issuer type is typically used in a private Public Key Infrastructure (PKI) setup to secure your infrastructure components to establish mTLS or otherwise provide a means to issue certificates where you also own the private key. Signed certificates with this custom CA will not be trusted by clients, such a web browser, by default.
31
+
32
+
### ACME issuers (Lets Encrypt)
33
+
34
+
The ACME Issuer type represents a single account registered with the Automated Certificate Management Environment (ACME) Certificate Authority server. See section [Let's Encrypt certificates](#lets-encrypt-certificates).
35
+
36
+
37
+
{{site.data.alerts.important}}
38
+
39
+
CertManager has been configured to have in the cluster a private PKI (Public Key Infrastructure) using a self-signed CA to issue auto-signed certificates.
40
+
41
+
CertManager integration with Let's Encrypt has not been configured since my DNS provider does not suppport yet the API for automating DNS challenges. See open issue [#16](https://github.com/ricsanfre/pi-cluster/issues/16).
14
42
15
-
CertManager has been configured to issue selfsigned certificates.
16
43
{{site.data.alerts.end}}
17
44
45
+
46
+
## Cert Manager Usage
47
+
48
+
Cert-manager add a set of Kubernetes custom resource (CRD):
49
+
50
+
-`Issuer` and `ClusterIssuer`: resources that represent certificate authorities (CA) able to genertate signed certificates in response to certificate signed request (CSR). `Issuer` is a namespaced resource, able to issue certificates only for the namespace where the issuer is located. `ClusterIssuer` is able to issue certificates across all namespaces.
51
+
52
+
-`Certificate`, resources that represent a human readable definition of a certificate request that need to be generated and keep up to date by an issuer.
53
+
54
+
In order to generate new SSL certificates a `Certificate` resource can be created.
55
+
56
+
Once the Certificate resource is created, Cert-manager signed the certificate issued by the specified issuer and stored it in a `kubernetes.io/tls Secret` resource, which is the one used to secure Ingress resource. See kuberentes [Ingress TLS documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls)
57
+
58
+
```yml
59
+
apiVersion: v1
60
+
kind: Secret
61
+
metadata:
62
+
name: testsecret-tls
63
+
namespace: default
64
+
data:
65
+
tls.crt: base64 encoded cert
66
+
tls.key: base64 encoded key
67
+
type: kubernetes.io/tls
68
+
```
69
+
70
+
See further details in the [cert-manager documentation](https://cert-manager.io/docs/usage/certificate/)
71
+
72
+
73
+
### Securing Ingress resources
74
+
75
+
`Ingress` resources can be configured using annotations, so cert-manager can automatically generate the needed self-signed certificates to secure the incoming communications using HTTPS/TLS
76
+
77
+
As stated in the [documentation](https://cert-manager.io/docs/usage/ingress/), cert-manager can be used to automatically request TLS signed certificates to secure any `Ingress` resources. By means of annotations cert-manager can generate automatically the needed certificates and store them in corresponding secrets used by Ingress resource
78
+
79
+
Ingress annotation `cert-manager.io/cluster-issuer` indicates the `ClusterIssuer` to be used.
- Step 4: Confirm that the deployment succeeded, run:
43
136
44
137
```shell
45
138
kubectl -n certmanager-system get pod
46
139
```
47
140
48
-
## Self-signed Certificates
141
+
## Cert-Manager Configuration
142
+
143
+
A PKI (Public Key Infrastructure) with a custom CA will be created in the cluster and all certificates will be auto-signed by this CA. For doing so, A CA `ClusterIssuer` resource need to be created.
144
+
145
+
Root CA certificate is needed for generated this CA Issuer. A selfsigned `ClusterIssuer` resource will be used to generate that root CA certificate (self-signed root CA).
49
146
50
-
- Step 1: Create `ClusterIssuer`
51
-
In order to obtain certificates from cert-manager, we need to create an issuer to act as a certificate authority. We have the option of creating an `Issuer` which is a namespaced resource, or a `ClusterIssuer` which is a global resource. We’ll create a self-signed `ClusterIssuer` using the following definition:
147
+
- Step 1: Create selfsigned `ClusterIssuer`
148
+
149
+
First step is to create the self-signed issuer for being able to selfsign a custom root certificate of the PKI (CA certificate).
150
+
151
+
In order to obtain certificates from cert-manager, we need to create an issuer to act as a certificate authority. We have the option of creating an `Issuer` which is a namespaced resource, or a `ClusterIssuer` which is a global resource. We’ll create a self-signed `ClusterIssuer` using the following definition:
52
152
53
153
```yml
54
154
apiVersion: cert-manager.io/v1
@@ -59,44 +159,50 @@ In order to obtain certificates from cert-manager, we need to create an issuer t
59
159
selfSigned: {}
60
160
```
61
161
62
-
- Step 2: Configure Ingress rule to automatically use cert-manager to issue self-signed certificates
63
-
64
-
As stated in the [documentation](https://cert-manager.io/docs/usage/ingress/), cert-manager can be used to automatically request TLS signed certificates to secure any `Ingress` resources. By means of annotations cert-manager can generate automatically the needed certificates
162
+
- Step 2: Bootstrapping CA Issuers
65
163
66
-
Ingress annotation `cert-manager.io/cluster-issuer` indicates the `ClusterIssuer` to be used
67
-
68
-
Ingress rule example:
164
+
Bootstrap a custom root certificate for a private PKI (custom CA) and create the corresponding cert-manager CA issuer
tls: # < placing a host in the TLS config will determine what ends up in the cert's subjectAltNames
92
-
- hosts:
93
-
- example.com
94
-
secretName: myingress-cert # < cert-manager will store the created certificate in this secret.
191
+
ca:
192
+
secretName: root-secret
95
193
```
96
194
195
+
{{site.data.alerts.important}}
196
+
197
+
Algorithm used for creating private keys is ECDSA P-256. The use of this algorithm is required by the service mesh implementation I have selected for the cluster, Linkerd. RootCa and Linkerd identity issuer certificate must used ECDSA P-256 algorithm.
198
+
199
+
{{site.data.alerts.end}}
200
+
201
+
202
+
97
203
## Lets Encrypt Certificates
98
204
99
-
Lets Encrypt provide publicly validated TLS certificates for free. Not need to generate auti-signed SSL Certificates for the websites that are not automatic validated by HTTP browsers.
205
+
Lets Encrypt provide publicly validated TLS certificates for free. Not need to generate auto-signed SSL Certificates for the websites that are not automatic validated by HTTP browsers.
100
206
101
207
The process is the following, we issue a request for a certificate to Let's Encrypt for a domain name that we own. Let's Encrypt verifies that we own that domain by using an ACME DNS or HTTP validation mechanism. If the verification is successful, Let's Encrypt provides us with certificates that cert-manager installs in our website (or other TLS encrypted endpoint). These certificates are good for 90 days before the process needs to be repeated. Cert-manager, however, will automatically keep the certificates up-to-date for us.
102
208
@@ -121,7 +227,7 @@ Since Dec 2020, IONOS launched an API for remotelly configure DNS, and so the in
121
227
122
228
Unfortunally IONOS API is part of a beta program that it is not available yet in my location (Spain).
123
229
124
-
### Let`s Encrypt HTTP validation method
230
+
### Lets Encrypt HTTP validation method
125
231
126
232
HTTP validation method requires to actually expose a "challenge URL" in the Public Internet using the DNS domain associated to the SSL certificate.
Copy file name to clipboardExpand all lines: docs/_docs/index.md
+15-13Lines changed: 15 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,8 +2,8 @@
2
2
title: What is this project about?
3
3
permalink: /docs/home/
4
4
redirect_from: /docs/index.html
5
-
description: The scope of this project is to create a kubernetes cluster at home using Raspberry Pis and to use Ansible to automate the deployment and configuration. How to automatically deploy K3s baesed kubernetes cluster, Longhorn as distributed block storage for PODs' persisten volumes, Prometheus as monitoring solution, EFK stack as centralized log management solution and Velero and Restic as backup solution.
6
-
last_modified_at: "25-02-2022"
5
+
description: The scope of this project is to create a kubernetes cluster at home using Raspberry Pis and to use Ansible to automate the deployment and configuration. How to automatically deploy K3s baesed kubernetes cluster, Longhorn as distributed block storage for PODs' persisten volumes, Prometheus as monitoring solution, EFK stack as centralized log management solution, Velero and Restic as backup solution and Linkerd as service mesh architecture.
6
+
last_modified_at: "05-04-2022"
7
7
---
8
8
9
9
@@ -12,7 +12,7 @@ The scope of this project is to create a kubernetes cluster at home using **Rasp
12
12
13
13
This is an educational project to explore kubernetes cluster configurations using an ARM architecture and its automation using Ansible.
14
14
15
-
As part of the project the goal is to use a lightweight Kubernetes flavor based on [K3S](https://ks3.io/) and deploy cluster basic services such as: 1) distributed block storage for POD's persistent volumes, [LongHorn](https://longhorn.io/), 2) centralized monitoring tool, [Prometheus](https://prometheus.io/) 3) centralized log managemeent, EFK stack ([Elasticsearch](https://www.elastic.co/elasticsearch/)-[Fluentbit](https://fluentbit.io/)-[Kibana](https://www.elastic.co/kibana/) and 3) backup/restore solution for the cluster, [Velero](https://velero.io/) and [Restic](https://restic.net/).
15
+
As part of the project the goal is to use a lightweight Kubernetes flavor based on [K3S](https://ks3.io/) and deploy cluster basic services such as: 1) distributed block storage for POD's persistent volumes, [LongHorn](https://longhorn.io/), 2) centralized monitoring tool, [Prometheus](https://prometheus.io/) 3) centralized log managemeent, EFK stack ([Elasticsearch](https://www.elastic.co/elasticsearch/)-[Fluentbit](https://fluentbit.io/)-[Kibana](https://www.elastic.co/kibana/), 3) backup/restore solution for the cluster, [Velero](https://velero.io/) and [Restic](https://restic.net/) and 4) service mesh architecture, [Linkerd](https://linkerd.io/)
16
16
17
17
18
18
The following picture shows the set of opensource solutions used for building this cluster:
@@ -94,21 +94,23 @@ The software used and the latest version tested of each component
94
94
| OS | Ubuntu | 20.04.3 | OS need to be tweaked for Raspberry PI when booting from external USB |
95
95
| Control | Ansible | 2.12.1 ||
96
96
| Control | cloud-init | 21.4 | version pre-integrated into Ubuntu 20.04 |
97
-
| Kubernetes | K3S | v1.22.6| K3S version|
97
+
| Kubernetes | K3S | v1.22.7| K3S version|
98
98
| Kubernetes | Helm | v3.6.3 ||
99
99
| Computing | containerd | v1.5.9-k3s1 | version pre-integrated into K3S |
100
-
| Networking | Flannel | v0.15.1| version pre-integrated into K3S |
100
+
| Networking | Flannel | v0.16.13| version pre-integrated into K3S |
101
101
| Networking | CoreDNS | v1.8.6 | version pre-integrated into K3S |
0 commit comments