Security

Security, in the context of a Conductor Manager, means securing communication with the Conductor 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 Conductor Manager, and to ensure that the data sent to and from it is encrypted.
Controlling access to Conductor Manager, and permissions to perform actions, is implemented via Flask-Security, to support user authentication and authorization.

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

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

Studio Conductor security for client access focuses on the REST service, which this is the first and only access point of clients to Conductor Manager. All requests to Conductor Manager are authenticated and authorized before reaching their endpoint.
For example, when a Conductor Management Console 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 Studio Conductor-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.

Authorization

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

Roles and Permissions

Studio Conductor 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 Studio Conductor administration operations such as snapshot management. A user can be suspended using the deactivate command. A deactivated user cannot perform operations.

Isolation

Studio Conductor supports the concept of users, user groups, and tenants. These elements can be either defined locally in Studio Conductor, or taken from an external user management system (LDAP integration is native). In the latter case, passwords are not stored in Studio Conductor, 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 Studio Conductor 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

Scope

Communication from the external environment to Conductor 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 Conductor Agents and Conductor Manager (and within Conductor Manager) is the responsibility of Studio Conductor, and is determined by Studio Conductor. Studio Conductor generates the necessary certificates for internal communication. Credentials do not appear in log files (cloud/RabbitMQ/Cloudify).

Communication channels

• Internal services access the REST API/file server over HTTPS on port 53333 through the manager’s private IP with a Studio Conductor generated authentication token.
• External access to REST API/file server (e.g. CLI, UI) is done by default over HTTP through the manager’s public IP, but can be configured to use HTTPS with a customer-signed certificate. Authentication is done via a Studio Conductor generated authentication token or with user and password.
• Agents access the manager over two secure channels: AMQP (5671) and HTTPS (53333). By default agents access the manager over its private IP, but can be configured to use other additional IPs.

SSL for internal communication

All internal communications between internal services/agents and the REST API/RabbitMQ are done over SSL.

During the bootstrap, the manager creates (or accepts as input) an internal CA certificate and key. Studio Conductor then creates an SSL keypair with a matching certificate that contains the private IP and all the management network IPs as its CN value. The keypair is used by both RabbitMQ and REST API/file server for internal access.

As part of the agent’s installation script, Studio Conductor’s internal CA certificate is propagated to the agent’s host in order to validate the manager’s certificate. There are no agent-host certificates.

Customizing SSL for internal communication

You can override the internal Manager certificate, and the CA certificate in the Conductor Manager configuration. To provide a custom internal CA certificate for the agents to use, add the ca_certificate and optionally ca_key inputs must be set in the /opt/cloudify/config.yaml file during installation or update of the Conductor Manager. To provide a custom internal certificate, use the internal_certificate and internal_key inputs. If none are provided, Studio Conductor will generate the CA and the internal certificate automatically.

SSL mode for external communication

Conductor Manager, by default, doesn’t use SSL for external communication. You can set the manager to use ssl for the external communication during bootstrap or after bootstrap.

During bootstrap, you can edit the manager blueprint input. In the Security Settings section, set ssl_enabled parameter to true, in order to set the manager ssl mode.

You can set the rest_certificate and rest_key parameters, to use your own certificate. If missing, the manager will auto generate the certificate.

After initial install, you can alter the entries in /etc/cloudify/config.yaml and run cfy_manager configure again to change the Conductor Manager settings. You can also change the manager certificate by using the replace methods under cfy certificates.

When installing with ssl mode, the certificate will be copied to the local CLI profile. When using CA signed certificate, provide the CA as the external_ca_cert_path input.

In order to update the certificate in the CLI profile, run the following command: cfy profile set --rest-certificate CA_CERT_PATH

In case you renew the certificate, update it on the manager by using the replace methods under cfy certificates.

Additional Security Information

• All services required by Studio Conductor run under the Studio Conductor (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 Studio Conductor 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.
  
• Conductor 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 Conductor Manager instances within a cluster, as part of HA.
  

For more information about the secrets store, click here.