GitLab

Introduction

This MR changes the approach to how SSL keys and certificates are delivered to the frontend. Instead of passing them by SlapOS Master, the frontend cluster provides a way to directly put keys and certificates to master partition (so default SSL configuration for slaves) and each slave separately.

Thus this values are removed from request parameter of master frontend partition:

• apache-certificate
• apache-key

and those from request of slave frontend instance:

• ssl_crt
• ssl_key

They are replaced with HTTPS endpoints on respectively:

• master-key-generate-auth-url
• master-key-upload-url

and:

• key-generate-auth-url
• key-upload-url

Where the generate-auth-url is used for one time key-based authorisation which allows to upload (new or updated) key and certificates to upload-url.

Technical details

Uses KeDiFa for SSL key management instead of passing them through SlapOS Master.

Tasks

Critical ones, which can make deployment hard

• allow SLA for kedifa partition
• consider switching automatic-internal-kedifa-caucase-csr to true, as this will put less maintenance on the instance

Good to have, but won't disrupt us

• kedifa-getter has to be run outside of the slapos node instance processing, as there is no guarantee at all regarding the partition to be processed when new key is available (see how caucased-updater works), and so frontend-updater is needed (rather outside of kedifa egg, maybe provided locally here or in toolbox)
  • start with having certificate.pem with dummy /CN=dummy.example.com generated with openssl, just for caddy to start
  • use frontend-updater, which knows which certificate is main, and has list of slave certificates, which updates any certificate, and links/copies master one to slave ones
  • kedifa-frontend will reload caddy in safe manner
  • certificate managetes is moved out totally from the profiles
  • think about backward compatibility - have all non-0-ssl certificates stored somewhere, and let frontend-updater to decide which one to use
• instead of giving bad URLs with NotReadyYet transmit nothing as long as KeDiFa backend is not ready to be used
• support external Caucase for KeDiFa with kedifa_caucase_url in the request, it will result with not creating caucased on KeDiFa partition
• add promises for newly developed software (kedifa running, etc)
• ping KeDiFa release and use released version
• add management UI for Kedifa with SSL auth, especially to reset auth tokens (so user can regenerate)

Done

• automatically migrate -- read ssl_crt, ssl_ca_crt, ssl_key, apache-certificate, apache-key and maybe apache-ca-certificate and use it in case if nothing is available from KeDifA
• wait for !473 (merged) to be merged
• carefully review state after recent rebases (CA proxy verification)
• switch caucase to manual service certificate approval, current automatic is for testing
• wait for https://lab.nexedi.com/luke/kedifa/merge_requests/1
• implement "securely" csr_id:
  • use proper names for CSR on each cluster node, in a way, that they will be creating really unique CSR, as there might be one caucase for many clusters
  • each partition asking CSR to caucase shall provide HTTPS URL on which csr_id from caucase can be read, with self signed certificate used to serve the content
  • note what "securely" means: only bootstrap information stays in SlapOS master, attacker if (a) knows caucased http listening port AND (b) can hijack traffic to the new instance is able to get the human to issue them a certificate instead of frontend's
• randomise references used in KeDiFa (see https://lab.nexedi.com/luke/kedifa/merge_requests/1#note_68734 )
• assure that cryptography egg is build against locally provided libraries (!434 (comment 68838))
• use dumps where applicable (luke/slapos@d4cc5c79 (comment 69001))
• improve library support for various uses (luke/slapos@d4cc5c79 (comment 69002))
• create/update documentation about new way and inform user with failing, if old parameters are used (eg. key bla bla is dropped, use upload-key-url to put your certificate and check the documentation)
• check if master_reserved_reference and master-reserved-reference is really required and drop it as since KeDiFa slot reservation and randomisation it seems not needed
• make automatic kedifa_caucase approvals, since it is possible to check csr_ids of nodes, signing csr can be automated in case if internal Caucase is used
• adapt to automatic restart on software release upgrade
• update caucase
• reorganise commits
• review documentation
• AUTOCERT_DIR={{ directory_autocert }} in graceful script, but it seems that master cert is not caught by it, since it is elsewhere
• rebase on top of !442 (merged) when merged