...
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.
...
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
...
| Group | Property name | Component spec type | Blueprint type (input*/blueprint**) | Default | Description |
|---|---|---|---|---|---|
| external_cert | use_external_tls | input | input | true | A boolean that indicates whether the component uses AAF CertService to acquire operator certificate to protect external (between xNFs and ONAP) traffic. For a time being only operator certificate from CMPv2 server is supported |
| external_cert_directory | hardcoded in BP Generator | blueprint | /opt/app/dcae-certificate/external_cert | Directory where operator certificate and trusted certs should be created | |
| ca_name | hardcoded in BP Generator | input | RA | Name of Certificate Authority configured on CertService side (in cmpServers.json). Default RA_TEST corresponds to default CMPv2 testing configuration. | |
| output_type | hardcoded in BP Generator | input | P12 | Certificate output type | |
external_cert: external_certificate_parameters | common_name | hardcoded in BP Generator | input | <Specific for every blueprint> | Common name which should be present in certificate. Specific for every blueprint (e.g. dcae-ves-collector for VES) |
| sans | hardcoded in BP Generator | input | <Specific for every blueprint> | List of Subject Alternative Names (SANs) which should be present in certificate. Delimiter - : Should contain common_name value and other FQDNs under which given component is accessible, e.g. if xNFs uses ves-collector in request URL, such should be also present in SANs - e.g. dcae-ves-collector:ves-collector. |
...
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. Section very similar to example described on a dedicated page.
Configuration specific only for K8s plugin
...
| Group | Property name | Default | Description |
|---|---|---|---|
properties: application_config | external_keystore_path | /opt/app/dcae-certificate/external_cert/keystore.jks | Path to keystore with external certificate |
| external_keystore_password_path | /opt/app/dcae-certificate/external_cert/keystore.pass | Path to password for keystore with external certificate | |
| external_truststore_path | /opt/app/dcae-certificate/external_cert/truststore.jks | Path to truststore with external trust anchors | |
| external_truststore_password_path | /opt/app/dcae-certificate/external_cert/truststore.pass | Path to password for truststore with external trust anchors |
...
There are two ways to support DCAE multisite deployment:
- One which requires direct connectivity between EDGE cloud and CMPv2 server (which isn't so extraordinary if xNFs also use CMPv2 protocol to enroll certificates)
- One which doesn't require direct connectivity between EDGE cloud and CMPv2 server, but requires direct connectivity between EDGE cloud and central ONAP deployment.
...