...
| Gliffy | ||||
|---|---|---|---|---|
|
Assumptions
- Not all service will switch to TLS interface for El-Alto
- CBS deployments must support both HTTPS and HTTP in-parallel
- SDK library (python and java) have separate api/version to let application choose migration
- *Can* deploy two instances in the same pod (CBS http and CBS HTTPS) under the same K8S service
- CBS is not be enabled for client-auth
...
- Switch to newer version of libraries (CBS SDK for java and python CBS utils)
- If not using library, component must use DCAE_CA_CERTPATH and 10443 for CBS HTTPS connection besides removing logic for Consul service discovery for CBS service.
- An optional CBS_CONFIG_URL will be exposed providing the exact URL to be used for configuration retrieval. Application/Libraries can use this URL directly instead of constructing URL from HOSTNAME (which refers to ServiceComponentName) and CONFIG_BINDING_SERVICE env's. By default, this URL will use HTTPS CBS interface
- Update blueprint to use newer version of k8s plugin in blueprints (requires k8splugin version 1.4.13 or higher)
Discussion Notes
Updates from 10/17 discussion
Current implementation relies on trust.jks being available. Following options to be explored for SDK to interact with CBS HTTPS
- Option 1: Work/address issue around using cacert.pem for CBS connection (original proposal)
- Option 2: Enabled use_tls: true for all DCAE MS deployment (in blueprint) to ensure all AAF cert/trust and distributed (regardless of the MS/component being setup as server or not)
- Option 3: Modify K8s plugin to include trust.jks distribution by default along with cacert.pem
Current SDK change https://gerrit.onap.org/r/#/c/dcaegen2/services/sdk/+/94266/ relies on Option#2 and Piotr Wielebski reported issue on using cacert.pem
Updates from 10/24 discussion
Option3 preferred; Damian/Nokia team will analyze the impact for k8s plugin updates.