Page Comparison

Vijay 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 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 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

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 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 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 Kumar

Vijay Kumar