Dustin
0a9596d8bd
[Step CA] is an open-source online X.509 and SSH certificate authority service. It supports issuing certificates via various protocols, including ACME and its own HTTP API via the `step` command-line utility. Clients can authenticate using a variety of methods, such as JWK, Open ID Connect, or mTLS. This makes it very flexible and easy to introduce to an existing ecosystem. Although the CA service is mostly stateless, it does have an on-disk database where stores some information, notably the list of SSH hosts for which it has signed certificates. Most other operations, though, do not require any persistent state; the service does not keep track of every single certificate it signed, for example. It can be configured to store authentication information (referred to as "provisioners") in the database instead of the configuration file, by enabling the "remote provisioner management" feature. This has the advantage of being able to modify authentication configuration without updating a Kubernetes ConfigMap and restarting the service. The official Step CA documentation recommends using the `step ca init` command initialize a new certificate authority. This command performs a few steps: * Generates an ECDSA key pair and uses it to create a self-signed root certificate * Generates a second ECDSA key pair and signs an intermediate CA certificate using the root CA key * Generates an ECDSA key pair and SSH root certificate * Creates a `ca.json` configuration file These steps can be performed separately, and in fact, I created the intermediate CA certificate and signed it with the (offline) *dch Root CA* certificate. When the service starts for the first time, because `authority/enableAdmin` is `true` and `authority/provisioners` is empty, a new "Admin JWK" provisioner will be created automatically. This key will be encrypted with the same password used to encrypt the intermediate CA certificate private key, and can be used to create other provisioners. [Step CA]: https://smallstep.com/docs/step-ca/ |
||
|---|---|---|
| authelia | ||
| autoscaler | ||
| cert-manager | ||
| dch-webhooks | ||
| docker-distribution | ||
| dynk8s-provisioner | ||
| firefly-iii | ||
| home-assistant | ||
| hudctrl | ||
| ingress | ||
| jenkins | ||
| kitchen | ||
| metrics | ||
| ntfy | ||
| paperless-ngx | ||
| phpipam | ||
| postgresql | ||
| prometheus_speedtest | ||
| scanservjs | ||
| setup | ||
| step-ca | ||
| storage | ||
| README.md | ||
README.md
Dustin's Kubernetes Cluster
This repository contains resources for deploying and managing my on-premises Kubernetes cluster
Cluster Setup
The cluster primarily consists of libvirt/QEMU+KVM virtual machines. The Control Plane nodes are VMs, as are the x86_64 worker nodes. Eventually, I would like to add Raspberry Pi or Pine64 machines as aarch64 nodes.
All machines run Fedora, using only Fedora builds of the Kubernetes components
(kubeadm, kubectl, and kubeadm).
See Cluster Setup for details.
Jenkins Agents
One of the main use cases for the Kubernetes cluster is to provide dynamic agents for Jenkins. Using the Kubernetes Plugin, Jenkins will automatically launch worker nodes as Kubernetes pods.
See Jenkins Kubernetes Integration for details.
Persistent Storage
Persistent storage for pods is provided by Longhorn. Longhorn runs within the cluster and provisions storage on worker nodes to make available to pods over iSCSI.
See Persistent Storage Using Longorn for details.