Page History

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

Current implementation relies on trust.jks being available. Following options to be explored

• 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

link to the source- https://

docs.onap.org/

en/

latest/

submodules/dcaegen2.git/

docs/

3/11 - New k8plugin released (2.0.0) and corresponding CM container released. Platform updates completed. Need test of HV_VES with new plugin - Piotr Wielebski

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

5/6 - Below I've attached some notes regarding TLS support for DCAE Components: 

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.

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

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 KumarImage AddedDCAEGEN2-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

Branching/tagging completed for all DCAE repo except  dcaegen2 (documentation)

Documentation repo branching targetted for 04 May 2020 

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  -

 Image AddedDCAEGEN2-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