Please Note:

Plan Configuration Settings for Cloud Init

With a user-data file, you can set the initial password for the initial user, the default CA and server certificates, IPv6 network settings, a static IP, disk encryption, and HSM integration.

Note

Cloud-init configuration (user-data) files uses YAML syntax; indentation is important and tabs can not be used.

Configuring Initial Password for the Initial User

The initial password for the initial Application Administrator can be auto-generated using a cloud-init configuration file containing the following setting:

  #cloud-config
  keysecure:
      initial-user:
        generate-password: true

Configuring Default CA and Server Certificates

Two certificates are created by default during initial boot-strapping of the CipherTrust Manager, one Self-signed Root CA Certificate and one Server Certificate that is signed by the Root CA.

Note

CipherTrust Manager does not support dns/ip atm; only the emails field is supported, regardless of the oid setting.

Configuring Initial Default Certificates

Before the first boot of the system, the content of these certificates can be overwritten with the help of a cloud-init configuration as follows:

#cloud-config
keysecure:
    default-ca:
        CN: <Common Name of Root CA Certificate, for example "Cloud-init test CA">
        emails:
          - <Subject Alternate Name E-Mail, for example "foo@example.com">
          - ...
        names:
          - C: <Country, for example "US">
            ST: <State/province, for example "TX">
            L: <Location, for example "Austin">
            O: <Organization, for example "Gemalto Inc.">
            OU: <Organizational Unit, for example "Gemalto">
          - ...
        dns-names:
            - <Subject Alternate Name DNS-Name, for example "web.keysecure.local">
            - ...
        ip-addresses:
            - <Subject Alternate Name IP-Address, for example "13.32.240.3">
            - ...
    default-server-cert:
        CN: <Common Name of Server Certificate, for example "Cloud-init test server cert">
        emails:
          - <Subject Alternate Name E-Mail, for example "foo@example.com">
          - ...
        names:
          - C: <Country, for example "US">
            ST: <State/province, for example "TX">
            L: <Location, for example "Austin">
            O: <Organization, for example "Gemalto Inc.">
            OU: <Organizational Unit, for example "Gemalto">
          - ...
        dns-names:
            - <Subject Alternate Name DNS-Name, for example "web.keysecure.local">
            - ...
        ip-addresses:
            - <Subject Alternate Name IP-Address, for example "13.32.240.3">
            - ...

A working cloud-init configuration looks as follows:

#cloud-config
keysecure:
  default-ca:
    CN: Cloud-init test CA
    emails:
      - certadmin1@example.com
      - support1@example.com
    names:
      - C: US
        ST: TX
        L: Austin
        O: Gemalto Inc.
        OU: Gemalto
      - C: Sweden
        L: Gothenburg
        O: Gemalto AB
    dns-names:
      - web.keysecure.local
      - web.ciphertrustmanager.local
    ip-addresses:
      - 13.32.240.3
      - 93.184.216.34
  default-server-cert:
    CN: Cloud-init test server cert
    emails:
      - certadmin2@example.com
      - support2@example.com
    names:
      - C: US
        ST: MD
        L: Belcamp
        O: Gemalto Inc.
        OU: Gemalto
      - C: Sweden
        L: Stockholm
        O: Gemalto AB
    dns-names:
      - web.keysecure.local
      - web.ciphertrustmanager.local
    ip-addresses:
      - 13.32.240.3
      - 93.184.216.34

The only required field is 'CN'. If it is missing the rest are ignored. If any of the remaining are missing, they will be empty when the certificate is created. If there is no default-ca or default-server-cert section, the defaults will be used for the missing section.

Configuring IPv6

There are two formats for IPv6 configuration, 'auto' and 'dhcp'. All systems come configured to use 'auto' as the default.

To set 'dhcp' as the default, add the following cloud-init directive to the user-data:

#cloud-config
keysecure:
    netcfg:
        config_ipv6: dhcp

Note

This parameter must be set before the first boot of the system since it is ignored after the first boot.

Note

Do not use 'dhcp' on AWS if there are no IPv6 interfaces defined. This will result in a five-minute delay during each boot of your firmware.

Configuring the CipherTrust Manager with a Static IP

The CipherTrust Manager OVA and Qcow2 disk images can be configured with a Static IP using cloud-init. The configuration format is as follows:

Note

Static IP is only supported via cloud-init, and must be done on initial boot of a service.

#cloud-config
keysecure:
    netcfg:
        iface:
            name: <interface name>
            type: <static>
            address: <ip address to be assigned>
            netmask: <net mask in x.x.x.x format>
            gateway: <gateway ip address>
            dns1: <dns server's ip address, optional>
            dns2: <alternate dns server's ip address, optional>

The interface names vary between cloud providers. The current name for the first network interface for various clouds is listed in the table below. These names might change in the future depending on how a cloud provider presents the virtual network interface to the operating system.

Cloud Provider	First Network Interface Name
Alibaba	ens5
Amazon Web Services	ens5
Google Cloud	ens4
Microsoft Azure	eth0
Oracle Cloud	ens3
VMWare vSphere	ens32

Configuring Disk Encryption

For added security, the disk of CipherTrust Manager can be fully encrypted with the public SSH key.

Encryption can either be initiated when an instance is first launched with cloud-init or on an already deployed instance with CipherTrust Manager CLI commands.

After encrypting the disk, you need to unlock the encrypted instance on every boot using the 'ksctl diskenc secureboot' command and the private SSH key associated with the instance. See To unlock an encrypted instance. Disk encryption is always applied, and this behavior cannot be disabled. If you wish to store your keys on an unencrypted CipherTrust Manager, you can deploy a new CipherTrust Manager and then use backup and restore to transfer keys and other data.

Security Best Practices

We always recommend enabling disk encryption.
Because installation specific secrets are generated the first time a Virtual CipherTrust Manager instance is launched, it is recommended that the instance be encrypted at launch time when possible to ensure these secrets are never exposed.
Provide an externally signed certificate to the preboot interface if possible. As you cannot provide this certificate with cloud-init configuration, this is the preferred deployment sequence for Virtual CipherTrust Manager deployments:
1. Enable disk encryption with cloud-init.
2. Launch the Virtual CipherTrust Manager instance.
3. Upload an externally signed certificate.
4. Reboot the Virtual instance.
5. Verify the preboot certificate when unlocking the disk.

Encrypting an Instance at First Launch

To configure the instance to encrypt at launch, use the cloud-init settings below for private cloud deployments. You must provide the public SSH key you will associate with the CipherTrust Manager instance in OpenSSH format. The corresponding private key to unlock can be in OpenSSH, PKCS1, or PKCS8 format. The supported key algorithm is RSA. We recommend RSA 4096, with RSA 2048 as a minimum size for adequate security.

Note

ssh-keygen produces OpenSSH format public keys by default. You can also use ssh-keygen to convert an existing PEM public key to OpenSSH with ssh-keygen -y -f public_key.pem > public_key.pub

#cloud-config
diskenc:
    encrypt: true
ssh_authorized_keys:
    - <replace with user's ssh public key>

For public cloud deployments on Amazon Web Services, Google Cloud, Microsoft Azure or Oracle Cloud, the SSH key is already provided during virtual image configuration, so you don't have to specify the SSH key in the user-data file.

#cloud-config
diskenc:
    encrypt: true

This file must be passed to the CipherTrust Manager instances, which uses cloud-init to enable the encryption. How this file is passed to the CipherTrust Manager appliance depends on the environment in which it is run. For other examples of passing cloud-init config.dat file in supported environments, go to Deploying with Cloud Init.

Checking Encryption Status

To check the encryption progress, you can run following CLI command:

ksctl diskenc status -p

This returns a response similar to:

Encrypting...

14.81 GiB / 15.52 GiB [====================================>-----] 95.44% 11s

This command might time out during system restart or due to a slow connection. As an alternative, you can view the Console for the instance to see disk encryption progress.

Unlocking an Encrypted Instance

ksctl diskenc secureboot -i <ssh key used to launch the instance>

Note

We recommend uploading an externally signed certificate to the preboot, to allow more secure unlocking.

The instance will start up after the encryption has finished. To unlock the instance, you must run following CLI command and provide the SSH private key in PEM format. OpenSSH format private keys are not supported. This is required to unlock the instance and allow admins and users to login and configure the Virtual CipherTrust Manager or access their keys.

Configuring HSM Integration

The CipherTrust Manager can be configured to use an HSM as a root of trust. This can be done using cloud-init.

Note

HSM configuration is now performed through the API. Using the cloud-init method is not recommended because it exposes sensitive information, such as the partition password, that can be viewed by anyone with access to the associated AWS console. For more information refer to Hardware Security Module.

Note

Before connecting an HSM to the CipherTrust Manager, the HSM must be set up and configured by an HSM Administrator. This includes creating a partition and partition password, and generating a client certificate for the CipherTrust Manager.

To enable HSM integration using cloud-init, user-data is supplied to cloud-init. This file must be passed to the CipherTrust Manager instances that uses cloud-init to enable the encryption. How this file is passed to the CipherTrust Manager appliance depends on the environment in which it is run. For a list of supported environments, see Overview.

Note

Cloud-init configuration (user-data) files uses YAML syntax; indentation is important and tabs can not be used.

Example - Configuring CipherTrust Manager to use SafeNet Luna Network HSM

#cloud-config
keysecure:
    hsm:
        type: luna
        # Replace dummy partition name and password values below with your existing Luna HSM settings.
        conninfo: '{"partition_name": "kylo-partition","partition_password": "sOmeP@ssword"}'
        config:
            # luna host name or ip address
            host: 172.20.32.11
            # luna server PEM encoded cert
            server-cert: |
                    -----BEGIN CERTIFICATE-----
                    ...
                    -----END CERTIFICATE-----
            # luna client PEM encoded cert
            client-cert: |
                    -----BEGIN CERTIFICATE-----
                    ...
                    -----END CERTIFICATE-----
            # luna client PEM encoded cert private key
            client-cert-key: |
                    -----BEGIN RSA PRIVATE KEY-----
                    Proc-Type: 4,ENCRYPTED
                    DEK-Info: DES-EDE3-CBC,92852AD5AFE768B8
                    ...
                    -----END RSA PRIVATE KEY-----

Example - Configuring CipherTrust Manager to use AWS CloudHSM (cavium)

#cloud-config
keysecure:
    hsm:
        type: aws
        # Replace dummy crypto user credentials below with your actual CloudHSM CU credentials.
        conninfo: '{"partition_name": "cavium","partition_password": "hsmuser:password"}'
        config:
            # CloudHSM Cluster ENI IP Address
            host: 172.20.32.11
            # CloudHSM Cluster certificate
            server-cert: |
                    ----BEGIN CERTIFICATE----
                    ...
                    ----END CERTIFICATE----

Example - Configuring CipherTrust Manager to DPoD Luna Cloud HSM service

Note

DPoD cloud configurations are sometimes above the AWS size limit for user data. Verify the user data is 16KB or less, otherwise it will be ignored by AWS. If it is larger then remove unnecessary whitespace (e.g. ident lines with a single space) and comments.

#cloud-config
keysecure:
    hsm:
        # type: Specifies HSM type as dpod.
        type: dpod

        # conninfo: "partition_name" and "partition_password"
        # {
        #     "partition_name': '',  # HSM partition name provided during partition provisioning
        #     'partition_password': '',  # HSM Crypto Officer password
        #  }
        conninfo: '{"partition_name": "kylo-partition","partition_password": "sOmeP@ssword"}'

        # config: include the following attributes:
        # {
        #     'server_cert': '',  # Server certificate in PEM format from server-certificate.pem file.
        #     'partition_cert': '',  # Partition certificate in PEM format from partition-certificate.pem file
        #     'partition_ca_cert': '',  # Partition CA certificate in PEM format from partition-ca-certificate.pem file
        #     'cv_app_specific_data': '',  # CVAppSpecificData value from Chrystoki.conf file
        #     'cv_partition_data': '',  # PartitionData00 value from Chrystoki.conf file
        #  }
        #
        config:
            server_cert: |
                -----BEGIN CERTIFICATE-----
                ...
                -----END CERTIFICATE-----
            partition_cert: |
                -----BEGIN CERTIFICATE-----
                ...
                -----END CERTIFICATE-----
            partition_ca_cert: |
                -----BEGIN CERTIFICATE-----
                ...
                -----END CERTIFICATE-----
            cv_app_specific_data: <CVAppSpecificData>
            cv_partition_data: <PartitionData00>

Suggest A Change

Plan Configuration Settings for Cloud Init

Configuring Initial Password for the Initial User

Configuring Default CA and Server Certificates

Configuring Initial Default Certificates

Configuring IPv6

Configuring the CipherTrust Manager with a Static IP

Configuring Disk Encryption

Security Best Practices

Encrypting an Instance at First Launch

Checking Encryption Status

Unlocking an Encrypted Instance

Configuring HSM Integration

Example - Configuring CipherTrust Manager to use SafeNet Luna Network HSM

Example - Configuring CipherTrust Manager to use AWS CloudHSM (cavium)

Example - Configuring CipherTrust Manager to DPoD Luna Cloud HSM service

On this page