diff options
| -rw-r--r-- | auth/docker/Dockerfile.client | 2 | ||||
| -rw-r--r-- | auth/docker/Dockerfile.config | 2 | ||||
| -rw-r--r-- | auth/docker/agent.sh | 15 | ||||
| -rwxr-xr-x | auth/sample/bin/client.sh | 2 | ||||
| -rw-r--r-- | docs/sections/AAF_in_a_Nutshell.rst | 63 | ||||
| -rw-r--r-- | docs/sections/configuration/AAF_4.1_config.rst | 45 |
6 files changed, 69 insertions, 60 deletions
diff --git a/auth/docker/Dockerfile.client b/auth/docker/Dockerfile.client index e50810fe..111c3774 100644 --- a/auth/docker/Dockerfile.client +++ b/auth/docker/Dockerfile.client @@ -25,10 +25,10 @@ ENV VERSION=${AAF_VERSION} LABEL description="aaf_agent" LABEL version=${AAF_VERSION} -COPY logs /opt/app/aaf_config/logs COPY bin/client.sh /opt/app/aaf_config/bin/agent.sh COPY bin/aaf-auth-cmd-${AAF_VERSION}-full.jar /opt/app/aaf_config/bin/ COPY bin/aaf-cadi-servlet-sample-*-sample.jar /opt/app/aaf_config/bin/ +COPY logs /opt/app/aaf_config/logs COPY cert/*trust*.b64 /opt/app/aaf_config/cert/ RUN if [ -n "${DUSER}" ]; then chown -R ${DUSER}:${DUSER} /opt/app/aaf_config; fi diff --git a/auth/docker/Dockerfile.config b/auth/docker/Dockerfile.config index 9a5fbb47..7e442b2a 100644 --- a/auth/docker/Dockerfile.config +++ b/auth/docker/Dockerfile.config @@ -28,10 +28,10 @@ LABEL version=${AAF_VERSION} COPY data/sample.identities.dat /opt/app/aaf_config/data/ COPY etc /opt/app/aaf_config/etc COPY local /opt/app/aaf_config/local +COPY logs /opt/app/aaf_config/logs COPY cert /opt/app/aaf_config/cert COPY public /opt/app/aaf_config/public COPY CA /opt/app/aaf_config/CA -COPY logs /opt/app/aaf_config/logs COPY bin/service.sh /opt/app/aaf_config/bin/agent.sh COPY bin/pod_wait.sh /opt/app/aaf_config/bin/ COPY bin/aaf-auth-cmd-${AAF_VERSION}-full.jar /opt/app/aaf_config/bin/ diff --git a/auth/docker/agent.sh b/auth/docker/agent.sh index a2b11830..c330b1ce 100644 --- a/auth/docker/agent.sh +++ b/auth/docker/agent.sh @@ -36,7 +36,7 @@ for V in VERSION DOCKER_REPOSITORY HOSTNAME AAF_FQDN AAF_FQDN_IP DEPLOY_FQI APP_ case $V in DOCKER_REPOSITORY) PROMPT="Docker Repo" - DEF="" + DEF="nexus3.onap.org:10003" ;; HOSTNAME) PROMPT="HOSTNAME (blank for Default)" @@ -47,7 +47,12 @@ for V in VERSION DOCKER_REPOSITORY HOSTNAME AAF_FQDN AAF_FQDN_IP DEPLOY_FQI APP_ AAF_FQDN_IP) # Need AAF_FQDN's IP, because not might not be available in mini-container PROMPT="AAF FQDN IP" - DEF=$(host $AAF_FQDN | grep "has address" | tail -1 | cut -f 4 -d ' ') + LOOKUP=$(host "${AAF_FQDN}" | grep "has address") + if [ -z ${LOOKUP} ]; then + DEF= + else + DEF=$(echo ${LOOKUP} | tail -1 | cut -f 4 -d ' ') + fi ;; APP_FQI) PROMPT="App's FQI";; APP_FQDN) PROMPT="App's Root FQDN";; @@ -74,6 +79,7 @@ for V in VERSION DOCKER_REPOSITORY HOSTNAME AAF_FQDN AAF_FQDN_IP DEPLOY_FQI APP_ fi fi echo "$V=$VAR" >> ./aaf.props + declare "$V"="$VAR" fi done . ./aaf.props @@ -91,7 +97,6 @@ else fi function run_it() { - LINKS="--link aaf-locate" if [ -n "${DUSER}" ]; then USER_LINE="--user ${DUSER}" fi @@ -99,7 +104,6 @@ function run_it() { ${USER_LINE} \ -v "${VOLUME}:/opt/app/osaaf" \ --add-host="$AAF_FQDN:$AAF_FQDN_IP" \ - $LINKS \ --env AAF_FQDN=${AAF_FQDN} \ --env DEPLOY_FQI=${DEPLOY_FQI} \ --env DEPLOY_PASSWORD=${DEPLOY_PASSWORD} \ @@ -118,6 +122,9 @@ case "$1" in PARAMS="&& cd /opt/app/osaaf/local && exec bash" run_it -it --rm ;; + taillog) + run_it -it --rm + ;; *) run_it --rm ;; diff --git a/auth/sample/bin/client.sh b/auth/sample/bin/client.sh index 79edb9b0..7af8a974 100755 --- a/auth/sample/bin/client.sh +++ b/auth/sample/bin/client.sh @@ -50,7 +50,7 @@ if [ ! -d $LOCAL ]; then mkdir -p $LOCAL for D in bin logs; do mkdir -p $OSAAF/$D - cp $CONFIG/$D/*.* $OSAAF/$D + cp $CONFIG/$D/* $OSAAF/$D done fi diff --git a/docs/sections/AAF_in_a_Nutshell.rst b/docs/sections/AAF_in_a_Nutshell.rst index c81957e3..663e8deb 100644 --- a/docs/sections/AAF_in_a_Nutshell.rst +++ b/docs/sections/AAF_in_a_Nutshell.rst @@ -8,46 +8,61 @@ AAF in a Nutshell This is a quick overview of some of the core structures of AAF. A more detailed narrative description can be found at The New Person's Guide to AAF Parts of AAF - Basic Terms ---------- -a namespace is the container (sometimes called a "security domain" by other security systems) assigned to an application; for instance, "com.att.test"namespaces contain 1 or more roles +----------------------------- +A namespace is the container (sometimes called a "security domain" by other security systems) assigned to an application; for instance, "com.att.test"namespaces contain 1 or more roles roles contain permissions and users - 1. a role is where users and permissions meet; permissions are not granted directly to users, rather a perm is granted to a role and users are added to the role - 2. a role contains 0 or more permissions - 3. a role contains 0 or more users or APPID identities - 4. note that role memberships have an expiration date. The owner of the namespace must re-approve all role memberships periodically. All approval requests, role renewal reviews, credential expiration, etc, emails will go to the namespace owner. If the namespace owner doesn't act upon these emails, users/appid’s will lose their permissions. Applications will break. Restoring lost permissions is the responsibility of the namespace admins, not any AAF support tier. - -namespaces contain 1 or more permissions - 1. other than the access permissions discussed below, AAF does not care about permissions - 2. AAF does not interpret application-specific permissions; in other words, it's up to the applications developers to create a permission scheme. - 1. the general usage pattern is that an application will ask for all permissions associated with a user - 2. locally, the application interprets what the presence or absence of a permissions means -by default, every namespace has 2 "access" permissions: - 1. a read/write permission, for instance "org.onap.test.access * *" - 2. a read only permission, for instance "org.onap.test.access * read" - - by default, every namespace has an admin role, for instance "org.onap.test.admin" - 1. the admin role contains the read/write permission for the namespace; if you delete the admin role, or the read/write permission from the role, your admins will have no access to your namespace. This is bad. + #. a role is where users and permissions meet; permissions are not granted directly to users, rather a perm is granted to a role and users are added to the role + #. a role contains 0 or more permissions + #. a role contains 0 or more users or APPID identities + #. note that role memberships have an expiration date. + + - The owner of the namespace must re-approve all role memberships periodically. + - All approval requests, role renewal reviews, credential expiration, etc, emails will go to the namespace owner. + - If the namespace owner doesn't act upon these emails, users/appid’s will lose their permissions. Applications will break. + - Restoring lost permissions is the responsibility of the namespace admins, not any AAF support tier. + +Namespaces contain 1 or more permissions + #. other than the access permissions discussed below, AAF does not care about permissions + #. AAF does not interpret application-specific permissions; in other words, it's up to the applications developers to create a permission scheme. + + - the general usage pattern is that an application will ask for all permissions associated with a user + - locally, the application interprets what the presence or absence of a permissions means + +By default, every namespace has 2 "access" permissions: + #. a read/write permission, for instance "org.onap.test.access \* \*" + #. a read only permission, for instance "org.onap.test.access \* read" + +By default, every namespace has an admin role, for instance "org.onap.test.admin" + #. the admin role contains the read/write permission for the namespace + + - if you delete the admin role, or the read/write permission from the role, your admins will have no access to your namespace. This is bad. + see Documentation for Namespace Admins for commands related to namespaces, roles, permissions AppID Identity ---------- +----------------- To use a AppID in AAF, the AppID must be associated with a namespace - 1. The owner of the namespace MUST BE the sponsor of the AppID. - 2. The owner of the namespace/appid is the ONLY PERSON who can add the AppID to the namespace. - 3. Once added to a namespace, you will now have a AppID identity. For example, namespace=org.onap.test, AppID=m99999, the AppID identity will be m99999@test.onap.org - 1. note that the domain portion (the part after the "@") is the namespace name reversed + #. The owner of the namespace MUST BE the sponsor of the AppID. + #. The owner of the namespace/appid is the ONLY PERSON who can add the AppID to the namespace. + #. Once added to a namespace, you will now have a AppID identity. For example, namespace=org.onap.test, AppID=m99999, the AppID identity will be m99999@test.onap.org + + - note that the domain portion (the part after the "@") is the namespace name reversed + AppID Identities must always be lowercase. Use "m91266@test.onap.org", not "M91266@test.onap.com" AppID Credentials (passwords) ---------- +--------------------------------- Each AppID identity may have 1 or more credential records - each record will have its own expiration date - each record may or may not be associated with the same password + Once the owner of the namespace/AppID has created the initial AppID identity & password, any admin can add new credentials as long as she/he knows a current password. Here are some scenarios to illustrate some points about AAF's credentials: -Scenario 1: an application already running in an Instance needs to do their yearly AppID password update +Scenario 1: an application already running in an Instance needs to do their yearly AppID password update + - The AppID identity already has a credential, but it is expiring soon - The application's support team can create a new credential at any time - must enter an existing password to create a new one; store your passwords in a secure, manor. diff --git a/docs/sections/configuration/AAF_4.1_config.rst b/docs/sections/configuration/AAF_4.1_config.rst index 71976623..6bb48749 100644 --- a/docs/sections/configuration/AAF_4.1_config.rst +++ b/docs/sections/configuration/AAF_4.1_config.rst @@ -59,35 +59,22 @@ This file is available to reuse for multiple calls. More importantly, you should 'aaf.prop' Properties --------------------- -=================== =============== ============ -Query Tag Description -=================== =============== ============ -CADI Version VERSION Defaults to CADI version of this -AAF's FQDN AAF_FQDN PUBLIC Name for AAF. For ONAP Test, it is 'aaf-onap-test.osaaf.org' -Deployer's FQI DEPLOY_FQI In a REAL system, this would be a person or process. For ONAP Testing, the id is deployer@people.osaaf.org, password (see Dynamic Properties) is 'demo123456!' -App's Root FQDN APP_FQDN This will show up in the Cert Subject, and should be the name given by Docker. i.e. clamp.onap -App's FQI APP_FQI Fully Qualified ID given by Organization and with AAF NS/domain. ex: clamp@clamp.onap.org -App's Volume VOLUME Volume to put the data, see above. ex: clamp_aaf -DRIVER DRIVER Docker Volume type... See Docker Volume documentation -LATITUDE of Node LATITUDE Global latitude coordinate of Node (best guess in Kubernetes) -LONGITUDE of Node LONGITUDE Global longitude coordinate of Node (best guess in Kubernetes) -=================== =============== ============ - ---------------------- -Dynamic Properties ---------------------- - -These Properties do not automatically save in 'aaf.props', because... - - | Passwords should not be stored clear text, with the possible exception of constant Environment Recreation, where it is impractical. - | The IP of the AAF's FQDN is looked up, if possible. It can be set, however, when lookup isn't available. - -=================== =============== ============ -Query Tag Description -=================== =============== ============ -Deployer's Password DEPLOY_PASSWORD Password for the Deployer. Avoids storing, except where impossible otherwise. -IP of <AAF_FQDN> AAF_FQDN_IP IP for Name of AAF FQDN, if not available by normal lookup means -=================== =============== ============ +==================== ================= ============ +Query Tag Description +==================== ================= ============ +DOCKER REPOSITORY DOCKER_REPOSITORY Defaults to current ONAP Repository +CADI Version VERSION Defaults to current CADI (AAF) version +AAF's FQDN AAF_FQDN PUBLIC Name for AAF. For ONAP Test, it is 'aaf-onap-test.osaaf.org' +AAF FQDN IP AAF_FQDN_IP If FQDN isn't actually found with DNS, you will have to enter the IP. For 'aaf-onap-test.osaaf.org', it is '10.12.6.214' +Deployer's FQI DEPLOY_FQI In a REAL system, this would be a person or process. For ONAP Testing, the id is 'deployer@people.osaaf.org' +Deployer's PASSWORD DEPLOY_PASSWORD OPTIONAL!! REAL systems should not store passwords in clear text. For ONAP Testing, the password is 'demo123456!' +App's Root FQDN APP_FQDN This will show up in the Cert Subject, make it the App Acronym. i.e 'clamp' +App's FQI APP_FQI Fully Qualified ID given by Organization and with AAF NS/domain. ex: 'clamp@clamp.onap.org' +App's Volume VOLUME Volume to put the data, see above. ex: 'clamp_config' +DRIVER DRIVER Docker Volume type... See Docker Volume documentation. Default is 'local' +LATITUDE of Node LATITUDE Global latitude coordinate of Node (best guess in Kubernetes) +LONGITUDE of Node LONGITUDE Global longitude coordinate of Node (best guess in Kubernetes) +==================== ================= ============ ------------------------------- Typical ONAP Entity Info in AAF |