Overview

In Frankfurt release AAF was enhanced by Certificate Management Protocol ver. 2 (CMPv2) support. Such support is handled by new AAF's microservice called CertService. CertService provides certificates signed by external CMPv2 server - further on such certificates are called operators certificates. Operators certificates are meant to secure external ONAP traffic - traffic between network functions (xNFs) and ONAP. 

Together with CertService, AAF provides CertService's client, which is a docker image meant to be used to call CertService API in a secure way. CertService's client should be invoked by other ONAP components as Init container, which has a dedicated role - acquires certificate and passes it to application container. Call to CertService can be controlled by environment variables which are passed to this init container.

Goal

Goal of this feature is to integrate DCAE with CertService to acquire operator certificates meant to protect external traffic between DCAE's components (VES collector, HV-VES and DFC) and xNFs. For that reason K8s plugin which creates K8s resources from Cloudify blueprints must be enhanced with new TLS properties support. New TLS properties are meant to control CertService's client call in init containers section and environment variables which are passed to it.

This feature doesn't influence ONAP internal traffic which nowadays is protected by certificates issued by AAF's CertMan. If any affected component doesn't distinguish between internal and external communication, such needs to be introduced. So extra goal of this feature is to clearly fence these two communications and still use certificates issued by AAF's CertMan in internal ONAP traffic, while use operators certificates in external traffic.

Current state

Within Frankfurt release only one of the previously listed DCAE components (DFC) clearly distinguish between external and internal traffic. Other components (VES collector and HV-VES) uses certificates enrolled by AAF's CertMan to protect both - external and internal traffic.

DFC

As already mentioned, DFC protects external and internal traffic using two different pairs of certificate and trusted certificates. Such are configured by properties:

External traffic:
dmaap.ftpesConfig.keyCert: /opt/app/datafile/config/cert.jks
dmaap.ftpesConfig.keyPasswordPath: /opt/app/datafile/config/jks.pass
dmaap.ftpesConfig.trustedCa: /opt/app/datafile/config/trust.jks
dmaap.ftpesConfig.trustedCaPasswordPath: /opt/app/datafile/etc/cert/trust.pass

Internal traffic:
dmaap.security.enableDmaapCertAuth: false
dmaap.security.keyStorePasswordPath: /opt/app/datafile/etc/cert/key.pass
dmaap.security.keyStorePath: /opt/app/datafile/etc/cert/key.p12
dmaap.security.trustStorePasswordPath: /opt/app/datafile/etc/cert/trust.pass
dmaap.security.trustStorePath: /opt/app/datafile/etc/cert/trust.jks

VES collector

VES collector protects both external and internal traffic using the same certificate and trusted certificates. Such are configured by properties:

Current one is actually external one:
collector.keystore.file.location: /opt/app/dcae-certificate/cert.jks
collector.keystore.passwordfile: /opt/app/dcae-certificate/jks.pass
collector.truststore.file.location: /opt/app/dcae-certificate/trust.jks
collector.truststore.passwordfile: /opt/app/dcae-certificate/trust.pass

HV-VES collector

HV-VES collector protects both external and internal traffic using the same certificate and trusted certificates. Such are configured by properties:

Current one is actually external one:
security.keys.keyStoreFile: /etc/ves-hv/ssl/cert.jks
security.keys.keyStorePasswordFile: /etc/ves-hv/ssl/jks.pass
security.keys.trustStoreFile: /etc/ves-hv/ssl/trust.jks
security.keys.trustStorePasswordFile: /etc/ves-hv/ssl/trust.pass

Way forward

K8s plugin

So, to implement goal of this feature, K8s plugin must be enhanced to support following new blueprint properties in new external_cert section and extra properties in K8s plugin configuration listed in following table:

external_cert:
	use_external_tls
	external_cert_directory
	ca_name
	external_certificate_parameters:
		common_name
		sans
		country
		organization
		state
		organizational_unit
		location

Meaning of properties is described in following table. CertService's client properties are described in details on a dedicated page.

* - property available in blueprint inputs, so can be changed every deployment

** - property available in blueprint, doesn't need to be changed every deployment

*** - property not available in blueprint, but available in K8s plugin configuration. The same for all blueprints

If new properties are provided by blueprint and use_external_tls is set to true, K8s plugin must be able to create init containers section and within it add information about CertService's client image and pass all other variables as environment variables. Very similar to example described on a dedicated page. 

DCAE bluerprints

Cloudify blueprints must be adjusted to take advantage of new K8s plugin functionality and must provide extra properties which controls CertService's client call.

DCAE components

Components which don't distinguish between external and internal traffic must be refactored to support different certificates and trusted certificates on both traffics separately.