CloudStack CA Framework

,

Introduction

The CloudStack management server listens by default on port 8250 for agents, and this is secured by one-way SSL authentication using the management server’s self-generated server certificates. While this encrypts the connection, it does not authenticate and validate the connecting agent (client). Upcoming features such as support for container/application cluster services require certificate management, and the emerging common theme is that CloudStack needs an internal certificate authority (CA) that can provide and ensure security and authenticity of client-server connections, and issue, revoke and provision certificates.

Solution

To solve these problems, we designed and implemented a new pluggable CA framework with a default self-signed root CA provider plugin, that makes CloudStack a root CA. Initial support is available for securing KVM hosts and systemvm agents, along with communication between multiple management servers. The feature also provides new APIs for issuance, revocation, use, and provision of certificates. For more details, here is the functional specification of the feature.

The new CA framework and root CA provider plugin for CloudStack was accepted by the community recently, and will be available in CloudStack 4.11 (to be released in the near future).

How does it work?

The CA framework injects itself into CloudStack’s server and client components, and provides separation of independent policy enforcement and mechanism implementation. Various APIs such as APIs for issuance, revocation, and provision of certificates plugin into the mechanism implementation provided by a CA provider plugin. In addition, the feature supports the automatic renewal of expiring certificates on an agent or a host, and will alert admins for the same if auto-renewal is disabled or something goes wrong.

The feature ships with a built-in default root CA provider plugin that acts as a self-signed root CA authority, and issues certificates signed by its self-generated and signed CA certificate. It also allows developers to write their own CA provider plugin. If the configured CA provider plugin supports sharing of its CA certificate, a button will appear on the UI to download the CA certificate that can be imported to one’s browser, host, etc.

OK, what happens after we upgrade?

After upgrading CloudStack to a version which has this feature (e.g. 4.11), there will be no visible change and no additional steps are required. The root CA provider plugin will be configured and used by default and the global setting ca.plugin.root.auth.strictness will be set to false to mimic the legacy behaviour of one-way SSL authentication during handshake.

Post-upgrade, the CA framework will set up additional security (by means of keystore and certificates) on new KVM hosts and SystemVMs. If CloudStack admins want to enforce stricter security, they can upgrade and onboard all existing KVM and SystemVM agents, use the provisionCertificate API, set the global setting ca.plugin.root.auth.strictness to true (new CloudStack installations will have this setting set to true by default), and finally restart the management server(s). The SystemVM agents and (KVM) hosts will be in Up and connected state once two-way SSL handshake has correctly verified and authenticated the client-server connections.

Here’s a link to the official CloudStack Admin Documentation for more details.

About the author

Rohit Yadav is a Software Architect at ShapeBlue, the Cloud Specialists, and is a committer and PMC member of Apache CloudStack. Rohit spends most of his time designing and implementing features in Apache CloudStack.