-
Bug
-
Resolution: Done
-
Medium
-
Frankfurt Release
-
None
-
Frankfurt M3
The AAF GUI for managing x509 artifacts provides a field called "O/S User" (for Operating System User). The value of this field is used to set ownership of downloaded artifacts. The examples typically show 'root' as this value, and that works as expected. As ONAP components were asked to run services as non-root users and still use AAF-supplied SSL certificates, there is a need to grant the proper access permissions. When the "O/S User" field is set to a value that matches the expected non-root user in the service container, it partially works, but the SSL certificate artifact is not installed. To be clearer, part of the set of artifacts are installed, and do have the correct ownership and permissions, but not the critical certificate.
A workaround exists and is included in several OOM charts. i.e. an additional init container is used to explicitly chown on the set of artifacts that are downloaded as root-owned. But it would seem much cleaner to have the AAF artifact attribute match the non-root user of the container.
Example of the problem (using dmaap/dmaap-bc which relies on a jks cert):
When "O/S User" is root, the logs of the aaf_agent:2.1.5 init container contain:
#### Place Certificates (by deployer)
2020-03-11T20:22:22.470+0000 INIT [cadi] cadi_keyfile points to /opt/app/osaaf/local/org.onap.dmaap-bc.keyfile
2020-03-11T20:22:22.479+0000 INIT [cadi] https.protocols set by cadi_protocols in CADI Properties
2020-03-11T20:22:22.479+0000 INIT [cadi] jdk.tls.client.protocols set from Default Protocols
Writing to /opt/app/osaaf/local
Writing file /opt/app/osaaf/local/org.onap.dmaap-bc.jks
Writing file /opt/app/osaaf/local/org.onap.dmaap-bc.trust.jks
Writing file /opt/app/osaaf/local/org.onap.dmaap-bc.check.sh
Writing file /opt/app/osaaf/local/org.onap.dmaap-bc.crontab.sh
Backing up /opt/app/osaaf/local/org.onap.dmaap-bc.cred.props
2020-03-11T20:22:23.690+0000: Trans Info
{{ REMOTE Place Artifact 768.9915ms}}
{{ Reconstitute Private Key 0.338055ms}}Obtained Certificates
But when "O/S User" is dbc, the logs look like this:
#### Place Certificates (by deployer)
2020-03-12T13:45:03.236+0000 INIT [cadi] cadi_keyfile points to /opt/app/osaaf/local/org.onap.dmaap-bc.keyfile
2020-03-12T13:45:03.245+0000 INIT [cadi] https.protocols set by cadi_protocols in CADI Properties
2020-03-12T13:45:03.245+0000 INIT [cadi] jdk.tls.client.protocols set from Default Protocols
2020-03-12T13:45:04.135+0000: Trans Info
{{ REMOTE Place Artifact 373.99744ms}}FAILED to get Certificate
Initialization complete
and inspection of the directory shows only some artifacts:
+ ls -l /opt/app/osaaf/local
total 136
rw-rr- 1 dbc onap 16 Mar 12 13:45 VERSION
rw-rr- 1 dbc onap 548 Mar 12 13:45 org.onap.dmaap-bc.cred.props
r------- 1 dbc onap 2074 Mar 12 13:45 org.onap.dmaap-bc.keyfile
rw-rr- 1 dbc onap 278 Mar 12 13:45 org.onap.dmaap-bc.location.props
rw-rr- 1 dbc onap 1163 Mar 12 13:45 org.onap.dmaap-bc.props
rw-rr- 1 dbc onap 117990 Mar 12 13:45 truststoreONAPall.jks
- blocks
-
AAF-1102 Pods still run as root
- Closed