![Animated terminal showing autocert in practice](demo.gif)
To request a certificate you simply annotate your pods with a name to include in the injected certificate. Certificates are issued by your own **internal certificate authority** and mounted at `/var/run/autocert.step.sm` along with the corresponding private key and root certificate.
TLS (e.g., HTTPS) is the most widely deployed cryptographic protocol in the world. Mutual TLS (mTLS) provides end-to-end security for service-to-service communication and can **replace complex VPN** technologies to secure communication into, out of, and between kubernetes clusters. But **to use mTLS you need certificates issued by your own certificate authority (CA)**. Building and operating a CA, issuing certificates, and making sure they're renewed before they expire is tricky. Autocert does all of this for you.
Autocert certificates let you secure your data plane (service-to-service) communication using mutual TLS (mTLS). Services and proxies can limit access to clients that also have a certificate issued by your certificate authority (CA). Servers can identify which client is connecting improving visibility and enabling granular access control.
Once certificates are issued you can use mTLS to secure communication in to, out of, and between kubernetes clusters. Services can use mTLS to only allow connections from clients that have their own certificate issued from your CA.
It's like your own Let's Encrypt, but you control who gets a certificate.
## Getting Started
These instructions will get `autocert` installed quickly on an existing kubernetes cluster.
### Prerequisites
Make sure you've [`installed step`](https://github.com/smallstep/cli#installing) version `0.8.3` or later:
You'll also need [webhook admission controllers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) enabled in your cluster:
We'll be creating a new kubernetes namespace and setting up some RBAC rules during installation. You'll need appropriate permissions in your cluster (e.g., you may need to be cluster-admin).
TODO: Check whether you have cluster permissions..? GKE instructions here if you don't have them.
```
In order to grant these permissions you may need to give yourself cluster-admin rights in your cluster. GKE, in particular, does not give the cluster owner these rights by default. You can give yourself cluster-admin rights by running:
To enable `autocert` for a namespace the `autocert.step.sm=enabled` label (the `autocert` webhook will not affect namespaces for which it is not enabled). To enable `autocert` for the default namespace run:
In addition to enabling `autocert` for a namespace, pods must be annotated with their name for certificates to be injected. The annotated name will appear as the common name and SAN in the issued certificate.
To trigger certificate injection pods must be annotated at creation time. You can do this in your deployment YAMLs:
The `autocert` admission webhook should intercept this pod creation request and inject an init container and sidecar to manage certificate issuance and renewal, respectively.
#### How is this different than [`cert-manager`](https://github.com/jetstack/cert-manager)
#### Doesn't kubernetes already ship with a certificate authority?
Yes, but it's designed for use by the kubernetes control plane rather than by your data plane services. You could use the kubernetes CA to issue certificates for data plane communication, but it's probably not a good idea.
#### Why not use kubernetes CSR resources for this?