Watch
1
0
Fork
You've already forked www.xengi.de
0
This commit is contained in:
Ricardo (XenGi) Band 2025-08-01 20:32:12 +02:00
commit a0571769f6
No known key found for this signature in database
3 changed files with 14 additions and 39 deletions

View file

@ -1,5 +1,5 @@
---
Title: "K8s on NixOS - Chapter 0: Preface"
Title: K8s on NixOS - Chapter 0: Preface
Date: 2025-03-14
Modified: 2025-03-16
Category: software

View file

@ -1,5 +1,5 @@
---
Title: "K8s on NixOS - Chapter 1: Getting the nodes ready"
Title: K8s on NixOS - Chapter 1: Getting the nodes ready
Date: 2025-03-17
Category: software
Tags: nix, nixos, flakes, server, qemu, libvirt, ssh, make

View file

@ -1,5 +1,5 @@
---
Title: "K8s on NixOS - Chapter 2: Certificates (PKI)"
Title: K8s on NixOS - Chapter 2: Certificates (PKI)
Date: 2025-03-14
Category: software
Tags: certificates, ca, pki
@ -36,36 +36,17 @@ to also set `pathlenzero=true` for the intermediate CAs.
# Basic setup
```mermaid
flowchart TD
root(Etcd Root CA)
peer(Etcd Peer Certs)
client(Etcd Client Certs)
root --> peer
root --> client
```
We will have two Certificate Authorities. One for the Etcd cluster and another one for the Kubernetes cluster. That way
a Kubernetes client won't be able to become an Etcd client by accident or the other way around.
```mermaid
flowchart TD
root(Kubernetes Root CA)
apiserver(API Server Cert)
controller-manager(Controller Manager Cert)
kubelet-server(Kubelet Server Cert)
kubelet-client(Kubelet Client Cert)
proxy(Proxy Cert)
scheduler(Scheduler Cert)
root --> apiserver
root --> controller-manager
root --> kubelet-server
root --> kubelet-client
root --> proxy
root --> scheduler
```
Under the Etcd CA, will create a certificate for each Etcd peer and one for each Etcd client. Under the Kubernetes CA we
will create certs for the API server, the controller manager, server and client certs for the kubelet, the kube-proxy
and the scheduler. Most of them are client certs that will access the Kubernetes API server.
We will use [cfssl](https://cfssl.org) to create our Certificate Authority. You could do the same with just `openssl` if
you prefer that. `cfssl` comes with baked in defaults that make it easier to get the security right. So if you're no
cryptography expert, I would suggest using it. In the `./pki` directory of our repository we'll create a
`ca-config.json` file like this:
you prefer that. `cfssl` comes with baked in defaults that make it easier to get the security right and you can
configure them in easy to read JSON files. So if you're no cryptography expert, I would suggest using it. In the `./pki`
directory of our repository we'll create a `ca-config.json` file like this:
```json
{
@ -190,9 +171,10 @@ will create the file `./pki/k8s-root/k8s-root-csr.json` with this content:
## Create a client cert
As a last step we will create a client certificate for us. This cert will be used to talk to the kubernetes API.
As a last step we will create a client certificate for us. This cert will be used in `kubectl` to talk to the kubernetes
API server.
Here is the config file `./pki/etcd-peer/etcd-peer-csr.json` for it:
Here is the config file `./pki/k8s-admin/k8s-admin-csr.json` for it:
```json
{
@ -209,13 +191,6 @@ Here is the config file `./pki/etcd-peer/etcd-peer-csr.json` for it:
"OU": "etcd",
"ST": "Berlin"
}
],
"hosts": [
"localhost",
"::1",
"127.0.0.1",
"node-01",
"2001:db8:0:a::1"
]
}
```