This project aims to utilize a working cert-manager installation to provide certificates outside kubernetes as easy as possible.
What does cert-manager-selfservice (CMS) offer?
- Just make an http call to get your certificate, example: http://localhost:8030/api/v1/certificate/your.domain.tld/pem
- CMS creates certificates ressources automatically
- CMS keep track when certificates are accessed
- CMS cleanup certificates not requested in a time
You need a working cert-manager installation and issuer for the domains you want to get certificates.
Simply use the Helm Chart to get started.
Expose your selfservice by ingress for example, the following examples assume that the selfservice http is reachable under http://selfservice.example.com
Login to the target system that want to use a certificate, create an directory and simply execute the commands:
mkdir /etc/ssl/selfservice
wget -O /etc/ssl/selfservice/service.test.example.com.pem http://selfservice.example.com/api/v1/certificate/service.test.example.com/pem
This will request a certificte for domain service.test.example.com
from selfservice, at the very first request for this domain the file under /etc/ssl/selfservice/service.test.example.com.pem
will created empty.
This is because cert-manager creating certificates asynchronously the commonly used lets-encrypt certificates will normally take more than one minute to populate.
Selfservice will return HTTP Code 202 until the certificate is ready to use and normal Code 200 when its ready, this means you should check your request for HTTP Code 200.
This example script can be used to get certificates only when ready, this simple call will put the final certificate under /etc/ssl/selfservice/service.test.example.com.pem
when ready:
get-certificate.sh http://selfservice.example.com service.test.example.com
If you run it in a cronjob the certificate will automatically renewed regullary.
At the moment you need a working kubernetes cluster with cert-manager to get started in development.
Check out integration for creating cluster in place.
Just execute the following commands in project root to start development (docker, npm and go are required):
# Install dependencies
npm install -g swagger-cli yarn
go install github.com/deepmap/oapi-codegen/cmd/oapi-codegen@latest
go install github.com/go-delve/delve/cmd/dlv@latest
# Build web project
cd web
yarn
yarn build
cd ..
# Deploy a local kubernetes with cert-manager and cluster issuer for testing
./integration/cluster.sh start
# Start development of server, the debugger is waiting press F5 in vscode to attach
./debug --debug server --kubeconfig=/tmp/cms-kubeconfig --issuer-name=cms-development-cluster-issuer --kube-namespace=cms
# Hit F5 in vscode to attach
# Optional: Start development of web and use it as accesspoint
cd web
yarn dev
The API Server and Client are generated using OpenAPI, generation can be done with make generate
.
The following tools are needed to generate the OpenAPI files:
- SwaggerCLI:
npm install -g swagger-cli
- GO: oapi-codegen
- Typescript: openapi
The web project will bundled on build time into the executable, so you need to make sure the web project is build before.
The most simplest usage (for testing) would to run cert-manager-selfservice with your local kubeconfig, this can be done by:
./cert-manager-selfservice server --issuer-name your-issuer-to-use
Then you can request a certificate by calling: http://localhost:8030/api/v1/certificate/your.domain.tld/pem
If the certificate not exists a certificate ressource will automatically be created, until there is no valid secret (issued certificate) a HTTP 202 will be returned.
There a also other endpoints like crt
, key
, ca
, json
availiable.
There a serveral ways to easy start development and using live debugging provided by delve
The provided launch.json has a debug task Launch File
predefined, just hit start and it should run with the args provided in launch.json.
A more advanced way to test in an external Terminal is provided by the External Debugging
launch config and ./debug
script:
- Execute debug script with arguments as normal:
./debug server --issuer-name your-issuer-to-use
- Start the
External Debugging
session in vscode
Unfortunately the order is importend because vscode does not try to automatically connect after start.