Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »




JIRA Associated

CBS HTTPS support (DCAEGEN2-1515)

  1. CBS expose both secure/insecure + AAF cert (DCAEGEN2-1549)
  2. Deployment update (DCAEGEN2-1550)
  3. SDK impact (java- DCAEGEN2-1552 / python - DCAEGEN2-1551)

Problem Statement :

CBS Api’s are used by all Service components to retrieve the configuration from consul during startup (and for periodic polling after). To support ONAP S3P security needs, Configbinding Service apis should be switched to HTTPS. As this has impact across all DCAE services, this has to be introduced in phased manner. El-Alto focus will on getting CBS HTTPS deployed and corresponding libraries updated.


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


Migration Path

Following are impacts to components to be done in specified order


CBS Enhancement


  • Support HTTPS enablement via environment variable
    • TLS_FLAG - Boolean
    • CBS_PORT
  • Support ONAP AAF cert; path to be sourced based on ENV
    • AAF_CERT_LOC

Tommy’s implementation has 3 environment variables:

    • USE_HTTPS: set to “1” to use HTTPS, anything else is HTTP
    • HTTPS_KEY_PATH: path to the TLS private key
    • HTTPS_CERT_PATH: path to the TLS certificate

He uses port 10443 if USE_HTTPS is set to “1”, otherwise he uses port 10000


Deployment Enhancement (Helm chart updates)


  1. Modify existing dcae-config-binding-service charts to support the new environment and new CBS container version. TLS_FLAG=False and CBS_PORT= 10000 (externalPort)

USE_HTTPS=0

kubectl get svc -n onap | grep config

config-binding-service             NodePort       10.43.61.181    <none>                                 10000:30415/TCP    


    • Nodeport 30415 to be used as Dublin
    • Service name: config-binding-service will remain same as R4
    •  
  1. Setup additional dcae-config-binding-service-tls to support new CBS instantiation with TLS enabled; the primary difference will be on env setting - TLS_FLAG=True and CBS_PORT= 10002

                                    USE_HTTPS=1

    • Nodeport – 30471 can be assigned
    • Service name: config-binding-service-tls
  1. Expose the ONAP dcae cert using TLS init container
    • Mapped volume into CBS pod should be set under AAF_CERT_LOC environment variable.

Set HTTPS_KEY_PATH and HTTPS_CERT_PATH to proper values based on where the certs directory is mounted.


K8s plugin updates


  1. Cloudify deployments of service components should include following environments


    • CONFIG_BINDING_SERVICE=<http_cbs_service_name>
    • CONFIG_BINDIND_SERVICE_PORT=<http_cbs_service_externalport>
    • CONFIG_BINDING_SERVICE_TLS=<https_cbs_service_name>
    • CONFIG_BINDIND_SERVICE_TLS_PORT=<https_cbs_service_externalport>
    • CONFIG_BINDING_SERVICE_CLIENTCERT=<path>

                          Today we set CONFIG_BINDING_SERVICE.  Components either know the port or get it by doing a service lookup in Consul.   I guess we could add CONFIG_BINDING_SERVICE_TLS.
                           For the client cert, the current tls-info approach works.   You can get the certs mounted without enabling HTTPS on the server.

  1. Enable AAF cert distribution by default on path identified by CONFIG_BINDING_SERVICE_CLIENTCERT . This should be done regardless of tls_info setting in blueprint (tls_info to be used for components when certificate are required to be mounted also application specific path – this can be created as softlink to CONFIG_BINDING_SERVICE_CLIENTCERT)

See above.  I think we already have a way that works.  It lets the component tell us where to mount the cert, rather than having us dictate it.


Bootstrap pod


    1. Add new k8s plugin version including R4 version (1.4.13) in CM deployments

                   It will probably be 1.4.14 or higher.

                   Also, to keep existing components from breaking, continue to register “config-binding-service” and “config_binding_service” as services in Consul, with port 10000 as the service port.

                   But we won’t do the same for the TLS service.  As components change to use TLS, they should just use the Kubernetes DNS name for the service along with port 10443.


Library (CBS java sdk, CBS python util) Enhancement


  1. Verify if the new environment setting for TLS (below) added by K8s plugin is visible within POD.
    • CONFIG_BINDING_SERVICE_TLS=<https_cbs_service_name>
    • CONFIG_BINDIND_SERVICE_TLS_PORT=<https_cbs_service_externalport>
    • CONFIG_BINDING_SERVICE_CLIENTCERT=<path>
      1. If defined, use the secure end-point to interface with CBS
      2. If TLS envs are undefined, use R4 service name and port (10000) to interface with CBS

                                         We know that CBS will be deployed with TLS in R5, so the library should just use it, unless the caller of

                                         the library asks to use HTTP.

                                         Libraries should stop using Consul service discovery to find CBS.


ServiceComponents


    1. Switch to newer version of libraries (CBS SDK for java and python CBS utils)
    2. Update blueprint to use newer version of k8s plugin in blueprints


  • No labels