Page Comparison

...

• 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
• *CannotCan* deploy two instances in the same pod (CBS http and CBS HTTPS) under the same K8S service (To to be confirmed)

Migration Plan

Following are impacts to components to be done in specified order

...

1. Modify existing dcae-config-binding-service charts to support the new environment and new CBS container version.
   1. Modify values.yaml service property to include two services: secure and insecure.
   1. USE_HTTPS=0
   2. Nodeport 30415 to be used as Dublin
   3. K8S Service name: config-binding-service will remain same as R4
2. Setup additional dcae-config-binding-service-tls to support new CBS instantiation with TLS enabled; the primary difference will be on env/nodeport
   1. USE_HTTPS=1
   2. Nodeport 30471
   3. K8S Service name: config-binding-service-tls
3. Expose the ONAP dcae cert using TLS init container.
   1. Set HTTPS_KEY_PATH and HTTPS_CERT_PATH to proper values based on where the certs directory is mountedEach service has the following properties:
      1. enabled - boolean flag to allow enabling and disabling the service.  Allows running HTTP only, HTTPS only, or both.  The default setting for El Alto is that both are enabled.
      2. internalPort - the container port (10000 for HTTP, 10443 for https)
      3. externalPort - the port used by other components inside the cluster to reach the service (10000 for HTTP, 10443 for https)
      4. nodePort – the last two digits of the node port number (15 for HTTP, 14 for HTTPS)
   2. Modify  deployment.yaml to deploy:
      
      1. if the secure service enable flag is set to true:
         1. the tls-init initContainer that sets stores certs in a volume in the pod
         2. a container with an instance of the config-binding-service image, with the USE_HTTPS, HTTPS_KEY_PATH, and HTTPS_CERT_PATH  environment variables set to enable TLS
         3. a container with an instance of the filebeat logging forwarder, configured to read logs generated by the TLS-enabled instance of the config-binding-service
      2. if the insecure service enable flag is set to true:
         1. a container with an instance of the config binding service image, with the USE_HTTPS environment variable set to 0, to enable non-TLS (HTTP) operation
         2. a container with an instance of the filebeat logging forwarder, configured to read logs generated by the non-TLS instance of the config-binding-service (this prevents problems that would be caused if both containers tried to write into the same logging volume)
   3. Modify service.yaml to deploy a Service named config-binding-service with port definitions based on the service property in the values.yaml.   The default service configuration will create a NodePort service with two ports, one for HTTP (inside the cluster on port 10000, outside the cluster on port 30415) and one for HTTPS (inside the cluster on port 10443, outside the cluster on port 30414).

K8s plugin updates (DCAEGEN2-1550)

1. Cloudify deployments of service components should include following environments
• CONFIG_BINDING_SERVICE=<http_cbs_k8s_service_name>CONFIG_BINDING_SERVICE_TLS=<https_cbs<cbs_k8s_service_name>
• CONFIG_BINDING_SERVICE_CLIENTCERT=<path>
2. Enable AAF cert distribution by default on path identified by CONFIG_BINDING_SERVICE_CLIENTCERT.
   1. This step to be done regardless of tls_info setting in blueprint (tls_info to be used for components supporting HTTPS as server; in this case certificate are required to be mounted also application specific path specified – this can be created as softlink to path specified by CONFIG_BINDING_SERVICE_CLIENTCERT).

...