Certificates management

[ndegory]

Certificates have to be set at platform / stack deployment, and have to be renewed on a regular basis, or replaced in case of a security issue.

1. Certificates are deployed as Docker secret, and linked to services that need them.
   Docker secrets:
   • can't be updated
   • can't be removed as long as a service is using them
2. Certificates are created with certbot (which has a feature to renew certificates) in standalone mode on one server (nothing is listening on port 443 at that moment), but it's not clear how we can trigger a renewal of a certificate from there, and they expire after 90 days.

What should be the process to easily renew certificates and apply them on the cluster?

[ndegory]

Unlike Traefik, docker-cloud/haproxy does not generate certificate on the fly.
Certbot is not able to integrate with haproxy, and if haproxy is already listening on port 443, certbot can't generate / renew the certificate.

If we stick with docker-cloud/haproxy, one way to do it is to plan a maintenance window (short, a few seconds), frequency should be higher than once every 90 days, during which:

• deletion of the haproxy service (or scale to 0, if possible)
• run a certbot container, generate or renew the certificate(s)
• remove + create the certificate secret, or create a new one
• create the haproxy service (or scale back to original size), with the proper secret

We don't have scheduled tasks yet in AMP, so today we're not able to address it without system level operations.

[JosephGJ]

Taken from the certificate.md file as it will be removed.

Certificate management for AMP

For local deployment, amp will generate a self signed certificate. You'll have to accept it when you connect the first time to the services on local.appcelerator.io.

For remote deployment, if you want to use a valid DNS domain, you can upload a certificate on the Swarm to enable TLS flows.

If your domain is cloud.mydomain.net, the certificate should be signed for cloud.mydomain.net, dashboard.cloud.mydomain.net, gw.cloud.mydomain.net, examples.cloud.mydomain.net and service.cloud.domain.net. If you can get a wildcard certificate, it's even better.

As an admin user of the platform, you can replace the certificate in the swarm. For that, prepare the secret as a pem file (includind the private key, the certificate, and the certificate chain), create a new Docker secret in the swarm, and update the amp_proxy service to mount it as /run/secrets/certN.pem, with N = 1 to 9.

amp secret create amp_certificate_$(date +%Y%m%d)
amp service update --secret-add amp_certificate_$(date +%Y%m%d) amp_proxy
amp service update --secret-rm amp_certificate_old_one amp_proxy