|
| 1 | +# Automated certificate regeneration |
| 2 | + |
| 3 | +You can deploy a K8s CronJob to automatically regenerate certificates which are stored in CredHub. A typical example are load balancer certificates used in a bosh-bootloader environment. The CronJob calls `credhub regenerate <certificate name>`. This will extend the certificate's validity while all other properties remain unchanged. |
| 4 | + |
| 5 | +The automated regeneration is provided as separate Terragrunt module which must be deployed separately to enable the feature. |
| 6 | + |
| 7 | +## Prerequisites |
| 8 | + |
| 9 | +The certificate's CA must be stored in CredHub, and they must be correctly linked. |
| 10 | + |
| 11 | +## Configuration and deployment |
| 12 | + |
| 13 | +First, configure the list of certificates in your local `config.yaml`. Define one string with comma-separated certificate names, e.g.: |
| 14 | +``` |
| 15 | +certificates_to_regenerate: "/concourse/main/cert_1,/concourse/main/cert_2" |
| 16 | +``` |
| 17 | + |
| 18 | +Next, change to the directory `terragrunt/<concourse-instance>/automatic_certificate_regeneration` and call |
| 19 | +``` |
| 20 | +terragrunt apply --terragrunt-config cert_regen.hcl |
| 21 | +``` |
| 22 | +You should see that Terraform creates a new resource: |
| 23 | +``` |
| 24 | +resource "kubernetes_cron_job_v1" "automatic_certificate_regeneration" |
| 25 | +(...) |
| 26 | +``` |
| 27 | +Confirm with `yes`. Afterward, you can see a new CronJob in your K8s deployment: |
| 28 | +``` |
| 29 | +$ kubectl -n concourse get cronjobs |
| 30 | +NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE |
| 31 | +certificate-regeneration @monthly False 0 <none> 50m |
| 32 | +``` |
| 33 | +To test the CronJob, you can invoke it explicitly and check the logs: |
| 34 | +``` |
| 35 | +kubectl -n concourse create job --from=cronjob/certificate-regeneration cert-regen-job |
| 36 | +# wait a few seconds |
| 37 | +kubectl -n concourse get pods # search pod "cert-regen-job-<xyz>" |
| 38 | +kubectl -n concourse logs cert-regen-job-<xyz> |
| 39 | +``` |
| 40 | +You should see the output from CredHub: |
| 41 | +``` |
| 42 | +id: 68875a90-c1b7-4391-a2af-bd3a8f33ce47 |
| 43 | +name: /concourse/main/cert_1 |
| 44 | +type: certificate |
| 45 | +value: <redacted> |
| 46 | +version_created_at: "2024-05-07T12:23:43Z" |
| 47 | +(...) |
| 48 | +``` |
| 49 | + |
| 50 | +## Limitations |
| 51 | + |
| 52 | +It's possible to renew CAs with the CronJob. Note however that this would be a one-step renewal process which can result in downtimes. The full 4-step CA renewal process as described on https://github.com/pivotal/credhub-release/blob/main/docs/ca-rotation.md is not implemented. |
| 53 | + |
| 54 | +If you want to include the CA in the regeneration process, you can add it at the beginning of the list: |
| 55 | +``` |
| 56 | +certificates_to_regenerate: "/concourse/main/my_CA,/concourse/main/cert_1,/concourse/main/cert_2" |
| 57 | +``` |
| 58 | +The (self-signed) CA would be regenerated first and then the two certificates would be re-signed with the new CA and the validity would be extended. |
| 59 | + |
| 60 | +## Deletion |
| 61 | + |
| 62 | +To delete the CronJob, change to the directory `terragrunt/<concourse-instance>/automatic_certificate_regeneration` and call |
| 63 | +``` |
| 64 | +terragrunt destroy --terragrunt-config cert_regen.hcl |
| 65 | +``` |
0 commit comments