Uploaded image for project: 'Application Authorization Framework'
  1. Application Authorization Framework
  2. AAF-1112

aaf_agent fails to download certificate artifact when O/S User is non root

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Medium Medium
    • Frankfurt Release
    • 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

            dglfromatt dglfromatt
            dglfromatt dglfromatt
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: