Home > Blogs > OpenStack Blog for VMware > Tag Archives: CLI

Tag Archives: CLI

Barbican Consumption and Operational Maintenance

VMware Integrated OpenStack(VIO) announced the official support for Barbican, OpenStack secrets manager,  in version 5.1.  With Barbican, cloud Operators can offer Key Management as a service by leveraging Barbican API and command line(CLI) to manage X.509 certificates, keys, and passwords. Basic Barbican workflow is relatively simple –  invoke the secrets-store plugin to encrypt a secret on the store and decrypt a secret on retrieval. In addition to generic secrets management, some OpenStack projects integrate with Barbican natively to provide enhanced security on top of its base offering.  This blog will introduce Barbican consumption and operation maintenance through the use of Neutron Load Balancer as a Service (LBaaS).

Understanding Policies

Barbican scopes the ownership of a secret at the OpenStack project level.  For each API call, OpenStack will check to ensure the project ID of the token matches the project ID stored as the secret owner.  Further, Barbican uses roles and policies to determine access to secrets. Following roles are defined in Barbican::

  • Admin – Project administrator. This user has full access to all resources owned by the project for which the admin role is scoped.
  • Creator – Users with this role are allowed to create and delete resources.  Users with this role cannot delete other user’s resources managed within same project. They are also allowed full access to existing secrets owned by the project in scope.
  • Observer – Users with this role are allowed access to existing resources but are not allowed to upload new secrets or delete existing secrets.
  • Audit – Users with this role are only allowed access to the resource metadata. So users with this role are unable to decrypt secrets

VIO 5.1 ships with “admin” and “creator” role out of the box.  A project member must be assigned with the creator role to consume barbican.  Based on the above roles, Barbican defines a set of rules or policies for access control. Only operations specified by the matching rule will be permitted.

While the policy framework works well, but secrets management is never one size fits all, and there are limitations with the policy framework if fine-grain control is required.  Scenarios such as grant specific user access to a particular secret or upload a secret for which only the uploader has access needs OpenStack ACLs.  Please refer to ACL API User Guide for full details.

Supported Plugin

The Barbican key manager service leverages secret-store plugins to allow authorized users to store secrets.   VIO 5.1 supports two type of plugins, simple crypto and KMIP enabled. Only a single plugin can be active for a VIO deployment.  Secret stores can be software-based, such as a software token, or hardware devices such as a hardware security module (HSM).

Simple crypto plugin

The simple crypto plugin uses a single symmetric key, stored locally on the VIO controller in the /etc/barbican/barbican.conf file to encrypt and decrypt secrets.  This plugin also leverages local Barbican database and stores user secrets as encrypted blobs in the local database.    The reliance on local text file and database for storage is considered insecure, and therefore upstream community considers simple crypto plugin to be suitable for development and testing workloads only.

Secret store KMIP plugins

The KMIP plugin stores secrets securely in an external KMIP-enabled device. The Barbican database, instead of storing encrypted secrets, maintain location references of secrets for later retrieval. Client certificate-based authentication is the recommended approach to integrate the plugin with the KMIP enabled device.

A cloud operator must use the VIOCLI to specify a plugin:

KMIP:

sudo viocli barbican –secret-store-plugin KMIP \

–host kmip-server –port kmip-port  \

–ca-certs ca-cert-file [–certfile local-cert-file –keyfile local-key-file –user kmip-user –password kmip-password]

Simple Crypto:

sudo viocli barbican –secret-store-plugin simple_crypto

Example Barbican Consumption:

One of the most commonly requested use case specific to VIO is Barbican integration with Neutron LBaaS to offer HTTPS offload.  This is a five step process, we will review each step in detail.

  1. Install KMIP server (Greenfield only)
  2. Integrate KMIP using VIOCLI
  3. ACL update
  4. Workflow to create secret
  5. Workflow to create LBaaSv2

Please note, you must leverage OpenStack API or CLI for step #4.  Horizon support for Barbican is not available.

Install KMIP server

Production Barbican deployment requires a KMIP server.  In a greenfield deployment, Dell EMC CloudLink is a popular solution VMware vSAN customers leverage to enable vSAN storage encryption.  CloudLink includes both a key management server (KMS) as well as the ability to control, monitor and encrypt secrets across a hybrid cloud environment. Additional details on CloudLink is available from VMware solution exchange.

Integrate KMIP using VIOCLI

To integrate with CloudLink KMS or any other KMIP based secret store, simply login into the VIO OMS server and issue the following VIOCLI command;

Configure Barbican to use the KMIP plugin.

viocli barbican –secret-store-plugin KMIP

–user viouser \

–password VMware**** \

–host <KMIP host IP> \

–ca-certs /home/viouser/viouser_key_cert/ca.pem \

–certfile /home/viouser/viouser_key_cert/cert.pem \

–keyfile /home/viouser/viouser_key_cert/key.pem –port 5696

Successful completion of VIOCLI command performs following set of actions:

  • Neutron.conf update to include Barbican specific service_auth account.
  • Barbican environment specific information provided via VIOCLI
  • Barbican service endpoints definition on the HAproxy

ACL updates based on consumption

Neutron LBaaS relies on a Barbican service account to read and push certificates and keys stored in the Barbican containers to a load balancer.  The Barbican service user is an admin member of the service project, part of the OpenStack Local domain. Default Barbican security policy does not allow admin or member of one project to access secrets stored in a different project. In order for Barbican service user to access and push certificate and keys, tenant users must grant access to the service account.  There are two ways to allow access:

Option 1:

1). Tenant creator gives Barbican service user access using the OpenStack ACL command.  Cloud administrator needs to supply the UUID of the Barbican service account.

openstack acl user add -u <barbican_service_account UUID > $(openstack secret list | awk ‘/ cert1 / {print $2}’)

Repeat this command with each certificate, key, and container you want to provide Neutron access to.

Option 2:

2.) If cloud administrators are comfortable providing Neutron with access to secrets without users granting access to individual objects, cloud administrators may elect to modify the Barbican policy file. Implementing this policy change means that tenants won’t need to add the Neutron barbican service_user to every object, which makes the process of creating TERMINATED_HTTPS listeners easier. Administrators should understand and be comfortable with the security implications of this action before implementing this approach. To perform the policy change, use a custom-playbook to change the following line in the Barbican policy.json file:

From:   “secret:get”: “rule:secret_non_private_read or rule:secret_project_creator or rule:secret_project_admin or rule:secret_acl_read”,

To:   “secret:get”: “rule:secret_non_private_read or rule:secret_project_creator or rule:secret_project_admin or rule:secret_acl_read or role:admin”,

Please refer to my previous blog on custom-playbook.

Workflow to Create Secret:

This step assumes you have pre-created certificates and keys.  If you have not created keys and certificates before, please refer to this blog for details.  To follow steps outlined below, make sure to name your output files accordingly (server.crt and server.key).  To upload a certificate:

openstack secret store –name=’certificate’ \

–payload=”$(cat server.crt)” \

–secret-type=passphrase

Most of options are fairly self-explanatory, passphrase indicates a plain text.  Repeat the same command for keys:

openstack secret store –name=’private_key’ \

–payload=”$(cat server.key)” \

–secret-type=passphrase

you can confirm by listing out all secrets:

 

 

 

 

Final, create a TLS container pointing to both private key and certificate secrets:

openstack secret container create –name=’tls_container’ –type=’certificate’ \

                   –secret=”certificate=$(openstack secret list | awk ‘/ certificate / {print $2}’)” \

                   –secret=”private_key=$(openstack secret list | awk ‘/ private_key / {print $2}’)”

Workflow to create LBaaSv2

With Barbican service up and running,  ACL configured to allow retrieval of secret keys, let’s start to create a Load balancer and upload a certificate and key from the KMS server.  Load balancer creation workflow does not change with Barbican.  When creating a listener, be sure to specify TERMINATED_HTTPS as the protocol, and URL of the TLS container stored in Barbican.

Please note:  

  1. If you are testing Barbican against NSX-T, NSX-MGR must be running at least version 2.2 or higher.
  2. Example assumes pre-created test VMs,  t1 router, logical switch and subnets.
  • Create TLS enabled LB:

neutron lbaas-loadbalancer-create \

$(neutron subnet-list | awk ‘/ {subnet name} / {print $2}’) \

–name lb

 

 

 

 

 

 

  • Create listener with TLS

neutron lbaas-listener-create –loadbalancer lb1 \

–protocol-port 443 \

–protocol TERMINATED_HTTPS \

–name listener1 \

–default-tls-container=$(openstack secret list | awk ‘/ tls_container / {print $2}’)

 

 

 

 

 

 

  • Create pool:

neutron lbaas-pool-create \

–name pool1 \

–protocol HTTP \

–listener listener1 \

–lb-algorithm ROUND_ROBIN

  • Add members:

neutron lbaas-member-create pool1 \

–address <address1> \

–protocol-port 80 \

–subnet $(neutron subnet-list | awk ‘/ test-sub / {print $2}’)

neutron lbaas-member-create pool1 \

–address <address2> \

–protocol-port 80 \

–subnet $(neutron subnet-list | awk ‘/ test-sub / {print $2}’)

 

 

 

 

 

 

 

 

 

 

 

 

you can associate a floating IP address with the Loadbalancer VIP for services requiring external access.

 

 

 

 

 

 

 

 

To test out the new LB service, simply curl the URL using the floating IP:

viouser@oms:~$  curl -k https://192.168.120.130

 

 

Deploy OpenStack CLI Utilities for Managing Your Cloud

One question that has come up on the VMware Communities is, “How do I configure my desktop with the OpenStack CLI packages?”

Deploy The CLI Binaries

The community documentation has pretty good instructions on getting the various packages installed on Linux, Mac OS X, and even Windows. At a minimum, I recommend installing the following packages using pip:

  • python-novaclient
  • python-neutronclient
  • python-cinderclient
  • python-glanceclient
  • python-heatclient

example:

sudo pip install python-novaclient

If you would like an automated method for deploying the CLI utilities, check out my openstack-client GitHub repo, which leverages Vagrant. I selected Ubuntu 15.04 as my operating system since it comes with Python version 2.7.9.  Ubuntu 14.04 and earlier versions come with older Python versions which generate an annoying, but superficial, InsecurePlatformWarning message when you use the CLI.

Start Consuming OpenStack

Once you have configured your selected platform with the OpenStack CLI tools, it’s time to connect to VMware Integrated OpenStack!

If you have a verified SSL certificate in your installation, you can move forward with the openrc file that you can download from the Horizon Dashboard (see Figure 1).

OpenStack openrc file for use with the CLI utilities

Figure 1: OpenStack openrc file download location

If your VIO installation still has a self-signed certificate, you will need to work with the VIO administrator to get a copy of the vio.pem file stored on the load balancer VMs (/etc/ssl/vio.pem). Then, add the following line to your openrc file:

export OS_CACERT=/your/path/vio.pem

Be sure to specify the correct path in your file.

Next, load the openrc file contents as environment variables using the source command (Windows users will need to create environment variables that correspond to the openrc file contents using the standard System Properties dialog). You will be prompted for your password. Then, you will be able to run commands like nova list, cinder list, etc.

Let us know if you have any questions about getting the OpenStack CLI utilities working on your desktop!

Interested in learning more about VIO? Check out the VMware Product Walkthrough site and the VMware Integrated OpenStack product page.

Simplified Certificate Management with VMware Integrated OpenStack

SSL certificates allow developers to interact with an OpenStack cloud with the confidence that their communications are encrypted. In VMware Integrated OpenStack, we enable SSL encryption, by default, for users to access the various endpoints securely.  In addition, we make it easy to generate your certificate signing request (CSR) and to apply the certificate after it is received from your trusted Certificate Authority (CA).

When you first install VMware Integrated OpenStack, it is running with a self-signed certificate. In order to work with the CLI or API, you would need to use the OS_CACERT parameter during authentication. In addition, your web browsers will report that the identity of the site is not verified and will not trust the certificate that the OpenStack dashboard presents.

We strongly recommend that users obtain a certificate from a trusted CA for their production deployments. To that end, we make the CSR generation process easy for our users. The user simply logs in to the VMware Integrated OpenStack management server VM via SSH, and runs the following command:
sudo viocli deployment cert-req-create

The CSR will be generated and displayed to the screen.  Copy the CSR output, including the “BEGIN” and “END” lines, and paste it to a file. Submit this file to your CA.

When the signed certificate is returned, use the following syntax to apply it:
sudo viocli deployment cert-update -p -f /Your_Certificate_Path/cert.crt

The VMware Integrated OpenStack automation code then proceeds to deploy the certificate for use in your environment. When the process is complete, you can use the OpenStack CLIs and APIs without the OS_CACERT attribute, and your web browsers will trust the OpenStack dashboard as shown in Figure 1.

OpenStack SSL certificate requests are simplified with VIO

Figure 1: SSL certificate applied to a VMware Integrated OpenStack deployment

You can learn more about VMware Integrated OpenStack on the VMware Product Walkthrough site and on the VMware Integrated OpenStack product page.