Go to file
2017-08-07 22:28:56 +01:00
cmd Automatically register CRD types 2017-08-07 21:07:50 +01:00
docs Update example issuer 2017-08-07 22:28:56 +01:00
hack Update import paths 2017-08-07 14:46:58 +01:00
pkg Update generated files 2017-08-07 18:28:52 +01:00
vendor Update vendor/ 2017-08-07 21:08:01 +01:00
.gitignore Update .gitignore 2017-08-07 21:03:17 +01:00
.travis.yml make all in Makefile 2017-07-22 12:32:12 +01:00
Dockerfile.acmesolver Build acmesolver image 2017-08-06 23:51:53 +01:00
Dockerfile.controller Build acmesolver image 2017-08-06 23:51:53 +01:00
Gopkg.lock Update vendor/ 2017-08-07 21:08:01 +01:00
Gopkg.toml Update vendor/ 2017-08-05 00:36:25 +01:00
LICENSE add apache 2.0 license 2017-07-22 12:04:24 +01:00
Makefile Update import paths 2017-08-07 14:46:58 +01:00
README.md Update README.md 2017-08-07 22:02:59 +01:00

cert-manager

cert-manager is a Kubernetes addon to automate the management and issuance of certificates from an aribitrary issuing source.

It is loosely based upon the work of kube-lego and has borrowed some wisdom from other similar projects eg. kube-cert-manager.

Current status

This project is still heavily under development and is not ready for use yet. However, if you want to experiment, please do try running the current development build and reporting any issues you run into.

Requirements

  • Kubernetes cluster with CustomResourceDefinitions enabled (1.7+)

Deploying

To deploy the latest development version, run:

$ kubectl create -f docs/cert-manager.yaml

Getting started

To get started, I've created two example issuers in docs/acme-issuer.yaml. These are configured to support the clouddns challenge provider for ACME, but if you do not intend to test this functionality then feel free to remove the configuration for it.

Go ahead and create the issuer(s) with:

$ kubectl create -f docs/acme-issuer.yaml

This will register your account with the ACME server, and generate you an account private key if required in the process.

There are then three example Certificate resources in docs/acme-cert.yaml. One of these uses the ACME HTTP01 challenge solver, targetting an existing ingress with ingressName. This configuration is best chosen when using an ingress controller that behaves like the GCLB controller (ie. one ingress<>IP mapping). The other example uses the ingressClass field, which is best used for ingress controllers like nginx where Ingress resources are 'merged'.

The third certificate is configured to use the clouddns DNS01 challenge provider.

You can mix and match challenge mechanisms within a single certificate for different domains. Please test this out and report any issues on the repo.