You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Bug Reference

Unable to render Jira issues macro, execution error.

Introduction

In current CloudStack, the agent-management server communication is weakly secured by one way SSL authentication while encrypted (on port 8250/default) and allows for any client/agent to connect and be served by the management server. There are other services that need TLS/SSL security and upcoming features such as container/application service etc. require certificate management. The common issue is CloudStack has no certificate management to provide security for its internal component especially the agent-mgmt server and mgmt-mgmt server communication. The aim of this feature is to provide pluggable CA (certificate authority) management in CloudStack that can fetch/provision certificates to (new) host(s) and systemvms. As a default CA plugin, a root CA plugin will be implement where CloudStack becomes a self-signed Root Certificate Authority. Developers will have option to implement further integration with their TLS/SSL cert providers such as letsencrypt and other vendors.

Feature Specification

• A pluggable CA service framework will be implemented that provides pluggable means to
initialize SSLContexts in the management server. The plugins can implement their own trust
management to validate and verify incoming client request and security.
• A CA plugin can have its own specific settings, API etc.
• The pluggable CA service framework will enable a custom CA plugin to implement its own
background task service to monitor active agents/client list with expiring certificates, failing
authentication, send out alerts etc.
• Certificate lifecycle operations such as to create, renew, revoke, provision/propagate certificates
will be provided by the framework, however the mechanisms will be implemented by a CA
plugin.
• Two new CA plugins will be created:

  • A legacy CA plugin, 'legacy', will contain the current CloudStack mechanisms to validate a client connection which uses a trust-all strategy. Currently, in the Link class SSLContext initialization and trust-management is handled. We'll refactor and move this code to the legacy CA plugin

  • A root CA plugin, 'root', will be based on a self-signed root certificate that is created by the management server itself during initialisation. This plugin will have configurations and certificate data available in the database and provide means to create, renew, provision/propagate certificates to clients/agents. The root CA plugin will maintain an internal certificate revocation list, and provide means for automatic renewal and propagation of certificates to valid/active agents. Parts of expiring clients detection and renewal using a background thread may be provided by the framework.

• Server-side components that use the NioServer class, on initialization can have a keystore (a .keystore file, db-backed or externally) initialized by the configured CA plugin along with custom trust managers The root CA plugin will use db/file backed keystore, while the default CA plugin will continue to use a file-based keystore. Other implementations are out of scope of this FR. This also means that the root CA plugin will only be enabled for servers running in the management server(s) and not in agents on other systems.
• Client-side components that use the NioClient class such as the (CPVM/SSVM/KVM) agents will have access to a keystore file, such as the config location /etc/cloudstack/agent. The keystore file can be used by in-band (agent) and out-of-band mechanisms to add/remove/update client certificates.
• The CA service framework will add hooks to the resource manager to carry out host-trust initialization (when hosts are added) if the configured CA plugin supports such operations. The CA service, along with the configured CA plugin can use ssh and other means to initialize client certificates on a (KVM) host such as to provide means of capturing generated CSRs and creating/propagating the client certificates to the agent (host). A new command-answer pattern will be introduced for propagation and on- boarding of certificate with already connected/active agents.
• A new script will be implemented to allow for generation of client-side certificate and CSR. The script can be executed by in-band or out-of-band mechanisms, and participate in certificate provisioning operations.
• A (comma-separated) list of management servers can be supported in agents, where on connection/disconnection/reconnection they can cycle through the list. This may remove dependency of an explicit LB for port 8205 over multiple-management servers. However, the configuration of existing agents by the management server(s) with such a list of addresses of management servers, is out of scope of this FR. It may be discussed and addressed in a separate FR.
• The enforcement of the certificate requirement will be optional. The CA plugin can provide a strictness setting for the enforcement of client-side certificate validation. This will allow for a strategy to on-board an existing CloudStack deployment to use a new CA plugin with client-authentication and validation disabled until all hosts are updated and configured to use the CA plugin-provided certificates (provisioned in-band or out-of-band way).

High level component diagram

APIs

The framework will implement following APIs that accept a plugin option, these APIs provide certificate lifecycle management operation as supported by the plugin and may throw a not-supported exception: (some names may be changed during implementation, we'll update the FS accordingly)

o listCAProviders: returns the list of available CA provider plugins.
o listRootCertificate: (plugin specific) returns (single/chained) root public certificate that
can be imported by clients, browser etc.
o createCertificate: (plugin specific) creates and returns a client certificate.
o revokeCertificate: (plugin specific) revokes a previously created client certificate.
o renewCertificate: (plugin specific) renews an expiring/expired client certificate.
o deployCertificate: (plugin specific) provisions and propagates a client certificate to an
agent/host.

UI changes

  • Button to copy/download root public certificate as supported by the configured CA plugin.
  • Events, alerts in the UI.

Global Settings

TODO

 

  • No labels