Get the latest docs

You are looking at documentation for an older release. Not what you want? Go to the current release documentation.

Security, in the context of a Cloudify Manager, means securing communication with the Cloudify Manager and controlling who has permissions to use it to execute various operations.
Secured communication is achieved using SSL, which allows clients to validate the authenticity of the Cloudify Manager, and to ensure that the data sent to and from it is encrypted.
Controlling access to Cloudify Manager, and permissions to perform actions, is implemented via Flask-Security, to support user authentication and authorization.

Cloudify Manager is secured by default. It cannot be bootstrapped in a non-secured way.

Details about Cloudify’s SSL and Access Control implementation and configuration are provided below.

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.
For example, when a Web-interface user attempts to upload a new blueprint, a request is sent to the REST service’s /blueprints endpoint through port 80 / 443. The request only reaches the endpoint if the user is logged in and is authorized to upload blueprints. Similarly, a user who executes the CLI command cfy deployments list triggers a request to execute GET on /deployments that is only be successful if it includes valid credentials that identify an authorized user.
Requests generated by other HTTP clients (e.g. curl) must also include valid credentials. Required credentials are a user name and password, or a Cloudify-generated token, and a tenant name. If credentials are missing, invalid, or represent an unauthorized user, the request fails with a “401: Unauthorized User” error.


The /version endpoint is not a secured resource, and is therefore open to all users.


A combination of roles, permissions and multi-tenancy provides the framework for authorization and resource isolation.

Roles & Permissions

Cloudify includes built-in user roles with which users are associated:

  • Administrator
  • User

Each role has different permissions, ensuring a role-based access control operation. For example, users with the user role cannot perform Cloudify administration operations such as snapshot management. A user can be suspended using the deactivate command. A deactivated user cannot perform operations.


Cloudify supports the concept of users, user groups, and tenants. These elements can be either defined locally in Cloudify, or taken from an external user management system (LDAP integration is native). In the latter case, passwords are not stored in Cloudify, authentication is performed via LDAP and a token is generated and used for the user session.
A user can be associated with one or more groups, and one or more tenants.
A group can be associated with one or more tenant.

A user who is authenticated to Cloudify may only access resources that belong to the tenants to which that user has been assigned. Resource isolation is implemented for blueprints, artifacts, deployments, nodes, logs, events, and plugins.

An additional layer of permission control is implemented on resources, allowing private resource configuration. A resource that is created as private is only visible to the user who created that resource, and not to other users within the tenant. The exception is a user with an admin role, who has full access to all system resources.

All REST APIs, except admin APIs and the version API, require a tenant, and operations are associated with the specified tenant. In the case of Read operations, only information about the specified tenant is returned. In the case of Write operations, the resource is added to the specified tenant.

Admin APIs are provided for the following resources (and are available only to admin users):

  • Tenant management (CRUD)
  • User management (CRUD)
  • User group management (CRUD)
  • Snapshot management (CRD)
  • Cluster management (configuration of manager HA)
  • Maintenance mode activation/de-activation
  • Upgrade/rollback commands

RabbitMQ isolation is achieved through the use of virtual hosts and the association between hosts and users, which enables authorization at the queue/exchange level and results in isolation of queues between tenants. In this configuration it is impossible for a host VM from tenant A to access/request operations on host VMs that belong to tenant B.



Communication from the external environment to Cloudify Manager and its SSL/TLS configuration is the user’s responsibility (CA/host verification, etc.), where the endpoints include the UI and REST API. Communication between Cloudify agents and Cloudify Manager (and within Cloudify Manager) is the responsibility of Cloudify, and is determined by Cloudify. Cloudify generates the necessary certificates for internal communication. Credentials do not appear in log files (cloud/RabbitMQ/Cloudify).

Communication Channels

To simplify the architecture, the number of internal communication channels is reduced.

  • Agents poll for task execution requests by connecting to the RabbitMQ server on the manager.
  • Access to the file server or REST API occurs through a secured port (authn, authz, encryption) that is controlled by Cloudify.
  • Accessing a REST API internally is not handled by Cloudify. If a user enables enabled SSL/auth over port 80 and chooses to use a REST client, either from a plugin or a script, they must configure it correctly.

Certificate Propagation

Cloudify creates private/public keys for the transport that is used by both RabbitMQ and file server access. The certificate is used to identify Cloudify Manager, there are no agent-host certificates. The manager certificate is propagated automatically to the agent host as part of the agent installation.

Certificate propagation depends on agent installation, as described below:

  • SSH/WinRM: On agent installation, Cloudify uploads the certificate to the VM running the agent. Note that WinRM is not encrypted in Cloudify and might pose a security risk.
  • Cloud-init/Userdata: Injects the certificate as part of the agent installation script injected to the VM.
  • Provided: The user places the certificate in a static location on the VM.


SSL is enabled for agent-manager communication. In addition, using SSL for client-server communication is possible and ensures:

  • Privacy: All communications between the client the server are encrypted.
  • Trust: When a connection is established, Cloudify Manager presents a signed certificate to the client. The client can use that certificate to validate the authenticity of the manager.

Requests to Cloudify Manager can be addressed to its public or private IP address. By default, internal requests (i.e. requests sent from Cloudify Manager itself, or from agent hosts) are sent to the Cloudify Manager private IP address. External requests (i.e. requests originating from other, external clients) must be sent to the Cloudify Manager public address.

Each of the server’s IP addresses has a different SSL key pair, created with the matching address as its CN value. Incorrectly sending a request to either the private or public address could therefore fail, because Cloudify Manager might present the wrong SSL certificate to the client.

Using the Cloudify Manager SSL Certificate with a Floating IP Address

To enable access of Cloudify Manager from outside the network, you must replace the three certificate files located under /etc/cloudify/ssl/ with certificates that include both the private IP address and the public IP address.

Additional Security Information

  • All services required by Cloudify run under the Cloudify (and not root) user in the manager VM. The only exception is the parent process of Nginx, which runs as root in order to enable use of port 80. It is not recommended to change this behavior.
  • A secrets store is implemented inside the Cloudify PostgreSQL database, which provides a tenant-wide variable store:
    • Through usage of the secrets store, a user can ensure all secrets (such as credentials to IaaS environments, passwords, and so on) are stored securely and separately from blueprints, and adhere to isolation requirements between different tenants.
    • Users need not know the actual values of a secret parameter (such as a password), since they can just point to the secrets store.
    • Secrets can be added to the store using a SET function, and retrieved via GET.
    • Plugins can access the secrets store, to leverage the secrets when communicating with IaaS environments.
    • Cloudify Manager instances must be secured via SSL to ensure secrets are not passed on an unencrypted communication channel.
    • Use of PostgreSQL ensures that secrets are replicated across all Cloudify Manager instances within a cluster, as part of HA.

For more information about the secrets store, click here.


Security operations, such as authenticating success or failure and user details, are audited in dedicated log file on the management server.
The default configuration is:

audit_log_file: /var/log/cloudify/rest-security-audit.log
audit_log_level: INFO
audit_log_file_size_MB: 100
audit_log_files_backup_count: 20

  • audit_log_file Sets the full path to the auditing file on Cloudify Manager.
  • audit_log_level Modifying the log level produces more or less elaborate security auditing. Valid values are: CRITICAL, ERROR, WARNING, INFO or DEBUG.
  • audit_log_file_size_MB Limits the log file size. By default, the file is limited to 100 MB. When the file reaches that size, it is renamed with the extension “.1”, and a new log file is created (older files are renamed with the extension “.2”, “.3” and so on).
  • audit_log_files_backup_count Sets the maximum number of old log files to keep. By default, this value is 20, meaning that up to 20 log files can be created, after which the oldest file is removed.