General Configuration

a9s Framework Server Components

Each a9s Data Services Framework (DSF) component provides the following properties to configure the API endpoints:

Property	Note
protocols.https.cert	The single certificate (server/leaf certificate) that is used for the component. The X.509 certificate MUST be in PKCS#1 format and PEM encoded.
protocols.https.key	The private key for the protocols.https.cert. The private key MUST be in PKCS#1 format and PEM encoded. The private key MUST NOT be encrypted.
protocols.https.ca	The ordered certificate chain for the protocols.https.cert. The individual X.509 certificates MUST be in PKCS#1 format and PEM encoded. The first certificate MUST be the CA certificate that signed the certificate in protocols.https.cert. The last certificate MUST be the root CA certificate. The certificate chain can also only consist of the root CA.
protocols.https.tls_ciphers	Optional This is a property that sets the allowed TLS ciphers by providing a string containing a list of ciphers-filters separated by a colon. Every element of this list can be either a specific cipher suite or a cipher filter.

Using the tls_ciphers value

Here are some examples on how the value of the tls_ciphers property can be set

• A specific cipher suite: AES256-GCM-SHA384.

• Multiple cipher suites: AES256-GCM-SHA384:ECDHE-RSA-CAMELLIA128-SHA256.

• A cipher filter that represents the list of cipher suites that contain a specific algorithm: SHA1 represent all the cipher filters that uses digest algorithm SHA1.

• You can use the operator + as a logical AND operation to allow for multiple algorithms to be specified. For example: SHA1+DES represents all cipher suites containing the SHA1 and DES algorithms.

  For more information on the tls_ciphers string format, you can check the [openssl/ciphers] (https://www.openssl.org/docs/man1.1.1/man1/ciphers.html) documentation.

Example:

protocols:
  http:
    enabled: true
    port: 3000
  https:
    enabled: true
    port: 3001
    ca: ((example_certificate.ca))
    cert: ((example_certificate.certificate))
    key: ((example_certificate.private_key))
    tls_ciphers: HIGH:!ADH:!RC4

This configuration applies to:

Name
a9s BOSH Deployer
a9s LogMe 2 SPI
a9s MariaDB SPI
a9s MongoDB SPI
a9s PostgreSQL SPI
a9s Prometheus SPI
a9s Messaging SPI
a9s Redis SPI
a9s Search SPI
a9s Backup Manager
a9s CF Service Guard

caution

Please note that the tls_ciphers property is not enabled for a9s Backup manager and a9s CF Service Guard.

Enable or Disable Endpoints

It is possible to

• have only plain-text endpoints (HTTP) enabled
• have only TLS-secured endpoints (HTTPS) enabled
• have both enabled at the same time

by setting the enabled property to either true or false.

danger

We strongly advise you to not permanently enable both protocols at the same time.

This is only useful for the transition of the a9s Framework from plain-text HTTP to TLS-secured HTTPS communication of the components.

Ports

The default port for most of the a9s components is 3000 for the plain text (HTTP).

The port for the TLS (HTTPS) interface is always HTTP port +1, so in most cases 3001.

An overview of the used ports in the a9s Framework can be found in the ports overview.

a9s Framework Client Components

This section describes the TLS configuration for outgoing connections to the servers using TLS.

info

Please keep in mind to replace [data_service] with the data services name, e.g.: rabbitmq, postgresql, and so forth.

a9s Service Broker

The a9s Service Broker communicates with the a9s SPIs:

properties:
  anynines_service_broker:
    service_adapter:
      name: Anynines::ServiceAdapters::ExternalSpi
      api_endpoint: https://[data_service]-service-spi.service.dc1.consul.example:3001
      username: admin
      password: (([data_service]_service_spi_password))
      ca: ((/a9s_private_components_ca.ca))

And the a9s BOSH Deployer:

properties:
  anynines_service_broker:
    bosh_deployer:
      api_endpoint: https://[data_service]-service-deployer.service.dc1.((iaas.consul.domain)):3001
      username: admin
      password: ((/[data_service]_service_deployer_password))
      ca: ((/a9s_private_components_ca.ca))

Errands

template-uploader

The template-uploader errand communicates with the a9s Deployer API. This is the configuration of the TLS properties:

properties:
  anynines_service_broker:
    bosh_deployer:
      api_endpoint: https://[data_service]-service-deployer.service.dc1.consul.example:3001
      skip-ssl-validation: false
      ca: ((/a9s_deployer_ca.certificate))((/a9s_components_ca.certificate))
      password: ((/[data_service]_service_deployer_password))
      username: admin

deployment-updater

The deployment-updater errand can be configured to communicate via TLS with the a9s Service Broker:

properties:
  deployment-updater:
    force-update: true
    service-broker-host: [data_service]-service-broker.service.dc1.consul.example
    service-broker-password: ((/[data_service]_service_broker_password))
    service-broker-protocol: 'https'
    service-broker-port: 3001
    service-broker-skip-ssl-validation: false
    service-broker-username: admin
    service-broker-ca: ((/a9s_[data_service]_broker_ca.certificate))((/a9s_components_ca.certificate))

a9s Dashboard Services

The a9s Dashboard Service communicates with the a9s Backup Manager.

properties:
  .
  .
  backup_manager:
    url: https://backup-service-backup-manager.service.dc1.((iaas.consul.domain)):3001
    username: admin
    password: ((/backup_manager_password))
    ca: ((/a9s_private_components_ca.ca))

And the a9s Service Broker:

properties:
  .
  .
  anynines_service_broker:
    service_broker:
      api_endpoint: http://postgresql-service-broker.service.dc1.((iaas.consul.domain)):3000
    authentication:
      http_auth_username: admin
      http_auth_password: ((/[data_service]_service_broker_password))

In addition, the a9s Dashboard Service exposes routing information to CloudFoundry's NATS server through its route_registrar process. The configuration for this communication is shown below:

- name: route_registrar
  release: routing
  consumes:
    nats-tls:
      deployment: cf
      from: nats-tls
  properties:
    nats:
      tls:
        client_cert: ((/cf_nats_tls_client_cert.certificate))
        client_key: ((/cf_nats_tls_client_cert.private_key))
        enabled: true

info

If BOSH links cannot be used for any reason, you can rely on the ops/static-nats-config-for-service-dashboards.yml to configure the communication between the a9s Service Dashboard and the NATS server. That ops-file will provide several other credentials manually.

The full list of credentials that are needed for the communication to NATS is provided below.

Credential	Note
cf_nats_tls_client_cert.certificate	The certificate that is provided to the route_registrar job of the dashboard for securing the communication with NATS.
cf_nats_tls_client_cert.private_key	The corresponding private key for the cf_nats_tls_client_cert.certificate.
cf_nats_tls_client_cert.ca	The ordered certificate chain for the cf_nats_tls_client_cert.certificate. The first certificate MUST be the CA certificate that signed the certificate in cf_nats_tls_client_cert.certificate. The last certificate MUST be the root CA certificate. The certificate chain can also only consist of the root CA. In any case, this credential should correspond to the one that has been provided in the NATS deployment for external connections. If you are relying on the BOSH links provided by the NATS deployment, you may omit this credential.
cf_nats_credentials.username	The username required to authenticate the route_registrar to NATS. If you are relying on the BOSH links provided by the NATS deployment, you may omit this credential.
cf_nats_credentials.password	The password required to authenticate the route_registrar to NATS. If you are relying on the BOSH links provided by the NATS deployment, you may omit this credential.