1
0
Fork 0
kubernetes/step-ca/README.md

61 lines
2.4 KiB
Markdown

# 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 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 R2* replaces *DCH Root CA R1*, which has not been used for some
time. *DCH Root CA R3* also exists, but it is based on an ED25519 signature,
which is not supported by Firefox.
## 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.
### ACME Provisioner
Hosts can obtain certificates signed by *DCH CA R2* 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.
[Step CA]: https://smallstep.com/docs/step-ca/
[ACME]: https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment