Cloudify was architected with security at top of mind and designed for real world production environments and the demanding workloads of our clients. However, to ensure editorial accuracy, when we refer to security in this post, we are actually referring to the internal workings of Cloudify Manager and the feature set that ensures enhanced security within the context of Cloudify.
Recently, we published a resource and user governance post detailing our Role-Based Access Control and multi-tenancy features to support user and resource isolation.
This post will focus on the security aspects not related directly to RBAC and multi-tenancy. Rather, it will cover aspects of internal and external communication, authentication and encryption, secrets, and other measures aimed at making Cloudify secure from within as well as outside of the organization.
Read the definitive Application Defined Governance whitepaper! Download Now
Secure Communication and Access
Cloudify utilizes SSL to support both internal communication between its own services, and external communication between Cloudify Manager and its users. Cloudify security for client access focuses on the REST service, which this is the first and only access point of clients to Cloudify Manager. All requests to Cloudify Manager are authenticated and authorized before reaching their endpoint. The certificates used for all communication, internal and external, are separate, and customers can also use their own certificates or provide a Certificate Authority (CA) in order to sign the certificates.
Internal communication between Cloudify components runs on dedicated ports which are blocked from external access.
Controlling access to Cloudify Manager, and permissions to perform actions, is implemented via Flask-Security, to support user authentication and authorization. External access to Cloudify Manager through any method, be it the UI, CLI, REST, requires authentication. Authentication methods include user/pass, LDAP integration, as well as Okta (SSO) integration.
Cloudify uses RabbitMQ as its broker, and supports configurable security. RabbitMQ also requires a username and password, tenant, and certificate. You can read more about RabbitMQ broker security in our docs.
The secrets store is implemented inside the Cloudify PostgreSQL database, to provide tenant-wide variable storage (key-value pairs) for data that you do not want to expose in plain text in Cloudify blueprints. For example, you might not want to expose login credentials for a platform to all blueprint users. When you create a secret, both the key and value can be text strings, and you are given an option to upload a file containing the value as well.
With the secret store, you can make sure all secrets (for example credentials to different IaaS environments) are stored separately from blueprints, and adhere to isolation requirements between different tenants. In this way, you can include the secret’s key in your blueprints and not include the actual values in the blueprints and ensure they are not accessed by users without permissions. For more information, see the get_secret intrinsic function.
Future Security Plans
We plan to add some really important security features in the next release including Kerberos authentication which will give users the ability to configure the Cloudify REST service to accept Kerberos tickets, verify them, and extract user information from them using Flask security. We also plan to add an option for custom authentication modules which will allow users to implement their own user authentication. Another potential issue is brute force attacks on logins, so we are working on a user lockout mechanism which will keep bad actors out of your account after too many login attempts.
One more very important area of concern is the secrets. In our next release, we are planning to introduce encryption for secrets which will only add to the already implemented key-value store.
Built for Data Reliability & Integrity
On top of the security features built into Cloudify Manager, Cloudify was also designed for data reliability and integrity through its high availability and redundancy, fault tolerance, and remediation capabilities. By taking proactive corrective measures in the case of failures or even load – auto-scale and heal – the robustness required by real world enterprises can be ensured for mission critical applications.
Cloudify is comprised of various open source projects from Nginx to Postgres to Celery to InfluxDB (full list here), as well as our special sauce of core orchestration code and our various plugins (which is also powered by our awesome community!). Our intention is to provide not only the best multi-stack and multi-cloud orchestration tool, but to ensure user resources and communications are all separated and secured, and all data can be maintained in a synchronized and reliable manner.