Dustin
d08cc6fb0f
I never ended up using _Step CA_ for anything, since I was initially focused on the SSH CA feature and I was unhappy with how it worked (which led me to write _SSHCA_). I didn't think about it much until I was working on deploying Grafana Loki. For that project, I wanted to use a certificate signed by a private CA instead of the wildcard certificate for _pyrocufflink.blue_. So, I created *DCH CA R3* for that purpose. Then, for some reason, I used the exact same procedure to fetch the certificate from Kubernetes as I had set up for the _pyrocufflink.blue_ wildcard certificate, as used by Frigate. This of course defeated the purpose, since I could have just as easily used the wildcard certificate in that case. When I discovered that Grafana Loki expects to be deployed behind a reverse proxy in order to implement access control, I took the opportunity to reevaluate the certificate issuance process. Since a reverse proxy is required to implement the access control I want (anyone can push logs but only authenticated users can query them), it made sense to choose one with native support for requesting certificates via ACME. This would eliminate the need for `fetchcert` and the corresponding Kubernetes API token. Thus, I ended up deciding to redeploy _Step CA_ with the new _DCH CA R3_ for this purpose. |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| README.md | ||
| ca.json | ||
| intermediate_ca.crt | ||
| kustomization.yaml | ||
| namespace.yaml | ||
| root_ca.crt | ||
| secrets.yaml | ||
| step-ca.yaml | ||
README.md
Step CA
Step CA is an open-source online X.509 and SSH certificate authority servier.
It provides an HTTP API for remote control via the step command, which is
used by clients for certificate issuance and administrators for configuration
and control. It also supports other certificate issuance protocols, including
ACME. Clients can authenticate using a variety of protocols, such as JWK,
OpenID Connect, mTLS, and more.
Offline Root CA
The DCH Root CA R3 private key is managed externally from Step CA. It is stored offline (on a flash drive in a fireproof safe). Only the CA certificate is used by the online CA service, where it is provided to clients to include in as a trust anchor in their respective certificate stores.
DCH Root CA R3 replaces DCH Root CA R2, which never ended up being used, and DCH Root CA R1, which has not been used for some time.
Online Intermediate CA
Step CA manages the DCH CA R3 intermediate certificate authority. The
private key for this CA is stored in the intermediate_ca.key file, encrypted
with the password in password. This key pair is needed by the online CA to
sign end-entity certificates.
ACME Provisioner
Hosts can obtain certificates signed by DCH CA R3 using the ACME protocol. The CA will only sign certificates for names that map to addresses controlled by the requesting client. For most machines, that means they can only get a certificate for their hostname. Other names can be added using DNS CNAME records.
Only the http-01 and tls-alpn-01 challenges will work, since clients cannot
modify DNS server records.
OIDC Provisioner
Step CA is configured to integrate with Authelia for OpenID Connect authorization. Users can obtain personal certificates using this provisioner.
NodePort Service (No Ingress)
Step CA supports authenticating clients using mTLS, such as to renew a user certificate. For this to work, the client must communicate directly with the server; proxies and load balancers must not intercept the communication or provide TLS termination, as then the server would not have access to the client certificate. As such, the service is exposed as a NodePort and not via an Ingress.