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/ |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| README.md | ||
| ca.json | ||
| intermediate_ca.crt | ||
| kustomization.yaml | ||
| namespace.yaml | ||
| root_ca.crt | ||
| ssh_host_ca_key.pub | ||
| ssh_user_ca_key.pub | ||
| 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 R2 private key is managed externally from Step CA. It is stored offline (on a flash drive in a fireproof save). 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 R2 replaces dch Root CA R1, which has not been used for some time.
Online Intermediate CA
Step CA manages the dch CA R2 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.
SSH CA
In addition to X.509 (TLS) certificates, Step CA can also manage SSH
certificates. These can be used in place of "plain" SSH keys that must be
managed out-of-band (i.e. ~/.ssh/known_hosts and ~/.ssh/authorized_keys).
Instead of maintaining a database of hosts' public keys, clients can trust the
CA certificate that signs the hosts' certificates. To do so, simply add a
single line to ~/.ssh/known_hosts:
@cert-authority *.pyrocufflink.blue ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJ8KfNjDh0R/jCmPcJrVafvmuw5JZw+cKoy9RCYNwHsRwPoRHfyzjV1VUZolJfEz+Qm3u+mgYJ/oSquCelY84xE=
Any host with a hostname that matches *.pyrocufflink.blue and presents a
certificate signed by the listed certificate will be automatically trusted; the
ssh client will not prompt for manual key verification on the first
connection.
Similarly, hosts can trust client keys that are signed by the CA by either
adding the certificate to per-user ~/.ssh/authorized_keys files or by
setting the global TrustedUserCAKeys parameter in the SSH server
configuration.
~/.ssh/authorized_keys:
cert-authority ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBImIoTTmhynCVy/vJ/Q2bWydzqVsvwhGvDgBbklw0eDt8UEbbP9HHPhxiMDtiAhbvRTg5BhYVAlR1MgdooT5dwQ=
/etc/ssh/sshd_config:
TrustedUserCAKeys /etc/ssh/ca.pub
/etc/ssh/ca.pub:
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBImIoTTmhynCVy/vJ/Q2bWydzqVsvwhGvDgBbklw0eDt8UEbbP9HHPhxiMDtiAhbvRTg5BhYVAlR1MgdooT5dwQ=
SSH host certificates are typically valid for 30 days, so hosts need to have
some automation in place to automatically renew their certificates. Using the
"SSHPOP" provisioner, hosts can use the step ssh renew command to renew their
certificates; existing signed SSH certificates are usable as authentication
credentials.
SSH user certificates are typically valid for 24 hours. Clients will need to
request a new certificate every day using the step ssh login command:
step ssh login --provisioner=authelia dustin
Note the --provisioner=authelia argument seems to be required, even if a
default provisioner is specified in ~/.step/config/defaults.json.
The final positional argument is the name of the remote SSH user, not the user logging in to the OIDC IdP.
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.