2020-05-13 DCAE Meeting Notes

Vijay Venkatesh Kumar

Release Status  

Frankfurt Milestone Status#RC1

• RC1 - DCAEGEN2-2203
• DCAE Pair Wise Testing for Frankfurt Release 
• CSIT failures - https://jenkins.onap.org/view/dcaegen2/   
• Review current list of release artifact version  (screenshot provided at the bottom)
  

DCAE Blockers/High priority

DCAEGEN2-2219 - DFC's SFTP client doesn't protect from MITM attacks (Guilin)  -  Plan to disable SFTP; need help with Test

Open items from last meeting

Vijay Venkatesh Kumar

Piotr Wielebski

Review recent discussion on :https://gerrit.onap.org/r/#/c/dcaegen2/services/sdk/+/94266/ and identify next step

Confluence:TLS support for CBS - Migration Plan

link to the source- https://docs.onap.org/en/latest/submodules/dcaegen2.git/docs/sections/tls_enablement.html

k8splugin version 2.0.0will automatically mount the CA certificate, in PEM and JKS formats, in the directory /opt/dcae/cacert. It is not necessary to add anything to the blueprint. To get the CA certificates in a different directory, add a tls_info property to the blueprint, set use_tls to false, and set cert_directory to the directory where the CA certs are needed.Whatever directory is used, the following files will be available:

• trust.jks:A Java truststore containing the AAF CA certificate. (Needed by clients that access TLS-protected servers.)
• trust.pass: A text file with a single line that contains the password for thetrust.jks keystore.
• cacert.pem: The AAF CA certificate, in PEM form. (Needed by clients that access TLS-protected servers.)

k8splugin version 2.0.0 uses an init container to supply the CA certificates.

4/29, 4/1 -tested on HV-VES 1.4.0-not working- Exception in thread "main" org.onap.dcaegen2.services.sdk.security.ssl.exceptions.ReadingPasswordFromFileException:Could not read password from /etc/ves-hv/ssl/jks.pass   

    - jks.pass is distributed only when use_tls is set to true; need to be checked if app expects cert as server? Piotr Wielebski

• Jira to be created to track - Vijay Venkatesh KumarDCAEGEN2-2240-CBS SDK error OPEN

5/13/ - after my investigation:

• CBS client works with k8s 2.0.0 plugin (attached log shows it)
• HV-VES requires the following certificates: trust.jks & trust.pass, cert.jks & cert.pass
• When certs are missing HV-VES is throwing an error ( | ERROR | Failed to create configuration: Could not read password from /etc/ves-hv/ssl/jks.pass )

Conclusion:

• HV-VES is a server app (just like PRH) 
• use_tls: true, is already set for Frankfurt (so everything should work)
• I think we can close this case

All repository branched including documentation (dcaegen2).  Committer must ensure new submissions are cherrypicked into Frankfurt branch

• dcaegen2/analytics/tca
• dcaegen2/analytics/tca-gen2
• dcaegen2/collectors/datafile
• dcaegen2/collectors/hv-ves
• dcaegen2/collectors/restconf
• dcaegen2/collectors/snmptrap
• dcaegen2/collectors/ves
• dcaegen2/deployments
• dcaegen2/platform
• dcaegen2/platform/blueprints
• dcaegen2/platform/configbinding
• dcaegen2/platform/deployment-handler
• dcaegen2/platform/inventory-api
• dcaegen2/platform/plugins
• dcaegen2/platform/policy-handler
• dcaegen2/platform/servicechange-handler
• dcaegen2/services
• dcaegen2/services/heartbeat
• dcaegen2/services/mapper
• dcaegen2/services/pm-mapper
• dcaegen2/services/prh
• dcaegen2/services/sdk
• dcaegen2/services/son-handler
• dcaegen2/utils

Fiachra Corcoran Jack Lucas

aaf_agent (2.1.20) changed in Frankfurt generates cert as non-root; need to assess impact to dcae TLS init (currently uses 2.1.15)

• one option is for separate truststore for external (discussed under CMPv2)
• resolve the ownership for current cert/truststore to non-root user (common onap usergroup + and add into separate container)
  • change aaf_agent to default to non-root

DCAE change to be assessed based on CMPv2 proposal; generic onap/usergroup to be discsussed with AAF team - Vijay Venkatesh Kumar

PMSH may need to support multiple instance per different usecase. The certificate generation should be supported at instance level (possible AAF dependency

5/13 - John Franey/AAF confirmed wild card supported in AAF.  Application can use AAF GUI to modify the SAN's (or bootstrap them via AAF/Windriver test). 

4/29 - Policy may be using wildcard - *.pdp, *.pdp.onap.svc.cluster.local ; to be confirmed if supported from AAF currently - Vijay Venkatesh Kumar

2/20  - DCAEGEN2-2084 - support certificate generation at instance level for DCAE services OPEN to track this request for DCAE; AAF dependency will be discussed post Frankfurt and corresponding AAF Jira to be created

Vijay Venkatesh Kumar

Vijay Venkatesh Kumar

JIRA cover broad aspect of standardizing DCAE component build process and docker tagging.

1. Nokia team proposal identifies best practice for docker tagging optimized-dockers-jvm.pdf. 
   1. Following components migrated to new docker tagging best-practice
      1. PRH
      2. PM-Mapper