Procedure

1. Log in to console.redhat.com.
2. Navigate to Automation Hub → Collections.
3. Set the toggle switch on each collection to exclude or include it on your synclist.
4. To initiate the remote repository synchronization, navigate to automation hub and select Collection → Repositories.
5. Click the More Actions icon ⋮ and select Sync to initiate the remote repository synchronization to your private automation hub.
6. Optional: If your remote repository is already configured, update the collections content that you made available to local users by manually synchronizing Red Hat Ansible Certified Content Collections to your private automation hub.

Procedure

1. Log in to console.redhat.com as an organization administrator.
2. Navigate to Automation Hub → Connect to Hub.
3. Under Offline token, click Load token.
4. Click Copy to clipboard to copy the API token.
5. Paste the API token into a file and store in a secure location.

Procedure

1. Log in to your private automation hub.
2. From the navigation panel, select Collections → Remotes.
3. In the rh-certified remote repository, click the More Actions icon ⋮ and click Edit.
4. In the URL field, paste the Sync URL.
5. In the Token field, paste the token you acquired from console.redhat.com.

6. Click Save.

   You can now synchronize collections between your organization synclist on console.redhat.com and your private automation hub.

7. Click the More Actions icon ⋮ and select Sync.

Procedure

1. Log in to automation hub.
2. From the navigation panel, select Collections → Remotes.
3. In the Community remote, click the More Actions icon ⋮ and select Edit.
4. In the YAML requirements field, click Browse and locate the requirements.yml file on your local machine.

5. Click Save.

   You can now synchronize collections identified in your requirements.yml file from Ansible Galaxy to your private automation hub.

6. Click the More Actions icon ⋮ and select Sync to sync collections from Ansible Galaxy and Ansible automation hub.

Procedure

1. Log in to private automation hub.
2. From the navigation panel, select Collections → Remotes.
3. In either the rh-certified or Community remote, click the More Actions icon ⋮ and select Edit.
4. Expand the Show advanced options drop-down menu.
5. Enter your proxy URL, proxy username, and proxy password in the appropriate fields.
6. Click Save.

Procedure

1. Create a signing script that accepts only a filename.

   Note

   This script acts as the signing service and must generate an ascii-armored detached gpg signature for that file using the key specified through the PULP_SIGNING_KEY_FINGERPRINT environment variable.

   The script prints out a JSON structure with the following format.

   {"file": "filename", "signature": "filename.asc"}

   All the file names are relative paths inside the current working directory. The file name must remain the same for the detached signature.

   Example:

   The following script produces signatures for content:

   #!/usr/bin/env bash
   
   FILE_PATH=$1
   SIGNATURE_PATH="$1.asc"
   
   ADMIN_ID="$PULP_SIGNING_KEY_FINGERPRINT"
   PASSWORD="password"
   
   # Create a detached signature
   gpg --quiet --batch --pinentry-mode loopback --yes --passphrase \
      $PASSWORD --homedir ~/.gnupg/ --detach-sign --default-key $ADMIN_ID \
      --armor --output $SIGNATURE_PATH $FILE_PATH
   
   # Check the exit status
   STATUS=$?
   if [ $STATUS -eq 0 ]; then
      echo {\"file\": \"$FILE_PATH\", \"signature\": \"$SIGNATURE_PATH\"}
   else
      exit $STATUS
   fi

   After you deploy a private automation hub with signing enabled to your Ansible Automation Platform cluster, new UI additions are displayed in collections.

2. Review the Ansible Automation Platform installer inventory file for options that begin with automationhub_*.

   [all:vars]
   .
   .
   .
   automationhub_create_default_collection_signing_service = True
   automationhub_auto_sign_collections = True
   automationhub_require_content_approval = True
   automationhub_collection_signing_service_key = /abs/path/to/galaxy_signing_service.gpg
   automationhub_collection_signing_service_script = /abs/path/to/collection_signing.sh

   The two new keys (automationhub_auto_sign_collections and automationhub_require_content_approval) indicate that the collections must be signed and approved after they are uploaded to private automation hub.

Procedure

1. Log in to your Ansible Automation Platform.
2. From the navigation panel, select Collections → Approval. The Approval dashboard opens and displays a list of collections.
3. Click Sign and approve for each collection that you want to sign.

Procedure

1. Log in to your automation hub.

2. From the navigation panel, select Signature Keys. The Signature Keys dashboard displays a list of multiple keys: collections and container images.

   • To verify collections, download the key prefixed with collections-.
   • To verify container images, download the key prefixed with container-.

3. Choose one of the following methods to download your public key:

   • Select the menu icon and click Download Key to download the public key.
   • Select the public key from the list and click the Copy to clipboard icon.
   • Click the drop-down menu under the Public Key tab and copy the entire public key block.

Procedure

1. To import a public key into a non-default keyring for use with ansible-galaxy, run the following command.

   gpg --import --no-default-keyring --keyring ~/.ansible/pubring.kbx my-public-key.asc

   Note

   In addition to any signatures provided by the automation hub, signature sources can also be provided in the requirements file and on the command line. Signature sources should be URIs.

2. To verify the collection name provided on the CLI with an additional signature, run the following command:

   ansible-galaxy collection install namespace.collection
   --signature https://examplehost.com/detached_signature.asc
   --signature file:///path/to/local/detached_signature.asc --keyring ~/.ansible/pubring.kbx

   You can use this option multiple times to provide multiple signatures.

3. Confirm that the collections in a requirements file list any additional signature sources following the collection’s signatures key, as in the following example.

   # requirements.yml
   collections:
     - name: ns.coll
       version: 1.0.0
       signatures:
         - https://examplehost.com/detached_signature.asc
         - file:///path/to/local/detached_signature.asc
   
   ansible-galaxy collection verify -r requirements.yml --keyring ~/.ansible/pubring.kbx

   When you install a collection from automation hub, the signatures provided by the server are saved along with the installed collections to verify the collection’s authenticity.

4. (Optional) If you need to verify the internal consistency of your collection again without querying the Ansible Galaxy server, run the same command you used previously using the --offline option.

Procedure

1. To obtain the tarball, navigate to the Red Hat Ansible Automation Platform download page and select Ansible Validated Content.

2. Upload the content and define the variables (this example uses automationhub_api_token):

   ansible-playbook collection_seed.yml
   -e automationhub_api_token=<api_token>
   -e automationhub_main_url=https://automationhub.example.com
   -e automationhub_require_content_approval=true

   Note

   Use either automationhub_admin_password or automationhub_api_token, not both.

Procedure

1. Log in to your private automation hub.
2. From the navigation panel, select User Access → Groups and click Create.
3. Enter Content Engineering as a Name for the group in the modal and click Create. You have created the new group and the Groups page opens.
4. On the Permissions tab, click Edit.
5. Under Namespaces, add permissions for Add Namespace, Upload to Namespace, and Change Namespace.

6. Click Save.

   The new group is created with the permissions that you assigned. You can then add users to the group.

7. Click the Users tab on the Groups page.
8. Click Add.
9. Select users and click Add.

Procedure

1. Log in to your private automation hub.
2. From the navigation panel, select Collections → Namespaces.
3. Click Create and enter a namespace name.
4. Assign a group of Namespace owners.
5. Click Create.

Procedure

1. Log in to your private automation hub.
2. From the navigation panel, select Collections → Namespaces.
3. Click the More Actions icon ⋮ and select Edit namespace.
4. In the Edit details tab, enter information in the fields.
5. Click the Edit resources tab to enter markdown in the text field.
6. Click Save.

Procedure

1. Log in to your private automation hub.
2. From the navigation panel, select Collections → Namespaces and select a namespace.
3. Click Upload collection.
4. Click Select file from the New collection dialog.
5. Select the collection to upload.
6. Click Upload.

Procedure

1. Log in to your private automation hub.
2. From the navigation panel, select Collections → Namespaces.
3. Select a namespace.
4. Click the More Actions icon ⋮ and select My imports.
5. Use the search field or locate an imported collection from the list.
6. Click the imported collection.
7. Review collection import details to determine the status of the collection in your namespace.

Procedure

1. Log in to your private automation hub.
2. From the navigation panel, select Collections → Namespaces.
3. Click the namespace to be deleted.

4. Click the More Actions icon ⋮, then click Delete namespace.

   Note

   If the Delete namespace button is disabled, the namespace contains a collection with dependencies. Review the collections in this namespace, and delete any dependencies. See Deleting a collection on automation hub for information.

Procedure

1. From the navigation panel, select Collections → Approval.

   Collections requiring approval have the status Needs review.

2. Select a collection to review.
3. Click the Version to view the contents of the collection.
4. Click Certify to approve the collection.

Procedure

1. From the navigation panel, select Collections → Approval.
2. Locate the collection to review.
3. Click Reject to decline the collection.

Procedure

1. Log in to automation hub.
2. From the navigation panel, select Collection → Repositories.
3. Click Add repository.
4. Enter a Repository name.
5. In the Description field, describe the purpose of the repository.

6. To retain previous versions of your repository each time you make a change, select Retained number of versions. The number of retained versions can range anywhere between 0 and unlimited. To save all versions, leave this set to null.

   Note

   If you have a problem with a change to your custom repository, you can revert to a different repository version that you have retained.

7. In the Pipeline field, select a pipeline for the repository. This option defines who can publish a collection into the repository.

   Staging

   Anyone is allowed to publish automation content into the repository.

   Approved

   Collections added to this repository are required to go through the approval process by way of the staging repository. When auto approve is enabled, any collection uploaded to a staging repository is automatically promoted to all of the approved repositories.

   None

   Any user with permissions on the repository can publish to the repository directly, and the repository is not part of the approval pipeline.

8. Optional: To hide the repository from search results, select Hide from search. This option is selected by default.
9. Optional: To make the repository private, select Make private. This hides the repository from anyone who does not have permissions to view the repository.
10. To sync the content from a remote repository into this repository, select Remote and select the remote that contains the collections you want included in your custom repository. For more information, see Repository sync.
11. Click Save.

Procedure

1. Log in to private automation hub.
2. From the navigation panel, select Collection → Repositories.
3. Locate your repository in the list and click the More Actions icon ⋮, then select Edit.
4. Select the Access tab.

5. Select a group for Repository owners.

   See Configuring user access for your private automation hub for information about implementing user access.

6. Select the roles you want assigned to the selected group.
7. Click Save.

Procedure

1. From the navigation panel, select Collection → Repositories.
2. Locate your repository in the list and click the More Actions icon ⋮, then select Edit.
3. Select the Collections version tab.
4. Click Add Collection and select the collections that you want to add to your repository.
5. Click Select.

Procedure

1. Log in to private automation hub.
2. From the navigation panel, select Collection → Repositories.
3. Locate your repository in the list and click the More Actions icon ⋮, then select Edit.
4. Locate the version you want to revert to and click the More Actions icon ⋮, and select Revert to this version.
5. Click Revert.

Procedure

1. Log in to automation hub.
2. From the navigation panel, select Collection → Repositories.

3. Locate your repository in the list and click Sync.

   All collections in the configured remote are downloaded to your custom repository. To check the status of the collection sync, select Task Management from the navigation panel.

   Note

   To limit repository synchronization to specific collections within a remote, you can identify specific collections to be pulled by using a requirements.yml file. See Create a remote for more information.

Procedure

1. Log in to Podman by using your registry.redhat.io credentials:

   $ podman login registry.redhat.io

2. Enter your username and password.

3. Pull a container image:

   $ podman pull registry.redhat.io/<container_image_name>:<tag>

1. List the images in local storage:

   $ podman images

2. Check the image name, and verify that the tag is correct.

Verification

1. List the images in local storage:

   $ podman images

2. Verify that the image you recently tagged with your automation hub information is contained in the list.

Procedure

1. Log in to Podman using your automation hub location and credentials:

   $ podman login -u=<username> -p=<password> <automation_hub_url>

2. Push your container image to your automation hub container registry:

   $ podman push <automation_hub_url>/<container_image_name>

Verification

1. Log in to your automation hub.
2. Navigate to Container Registry.
3. Locate the container in the container repository list.

Procedure

1. Log in to automation hub.
2. From the navigation panel, select Execution Environments → Execution Environments.
3. Select your container repository.
4. On the Detail tab, click Add.
5. In the Raw Markdown text field, enter your README text in Markdown.
6. Click Save when you are finished.

Procedure

1. Log in to automation hub.
2. From the navigation panel, select Execution Environments → Execution Environments.
3. Select your container repository.
4. From the Access tab, click Select a group.
5. Select the group or groups to which you want to grant access and click Next.
6. Select the roles that you want to add to this execution environment and click Next.
7. Click Add.

Procedure

1. From the navigation panel, select Execution Environments → Execution Environments.
2. Select your container repository.
3. Click the Images tab.
4. Click the More Actions icon ⋮, and click Manage tags.
5. Add a new tag in the text field and click Add.
6. Optional: Remove current tags by clicking x on any of the tags for that image.
7. Click Save.

Procedure

1. Navigate to automation controller.
2. From the navigation panel, select Resources → Credentials.
3. Click Add to create a new credential.
4. Enter an authorization Name, Description, and Organization.
5. Select the Credential Type.
6. Enter the Authentication URL. This is the container registry address.
7. Enter the Username and Password or Token required to log in to the container registry.
8. Optional: To enable SSL verification, select Verify SSL.
9. Click Save.

Procedure

1. If you are pulling container images from a password or token-protected registry, create a credential in automation controller before pulling the image.
2. From the navigation panel, select Execution Environments → Execution Environments.
3. Select your container repository.
4. In the Pull this image entry, click Copy to clipboard.
5. Paste and run the command in your terminal.

Procedure

1. From the navigation panel, select Execution Environments → Execution Environments.
2. Add https://registry.redhat.io to the registry.

3. Add any required credentials to authenticate.

   Note

   Some container registries are aggressive with rate limiting. Set a rate limit under Advanced Options.

4. From the navigation panel, select Execution Environments → Execution Environments.
5. Click Add execution environment in the page header.

6. Select the registry you want to pull from. The Name field displays the name of the image displayed on your local registry.

   Note

   The Upstream name field is the name of the image on the remote server. For example, if the upstream name is set to "alpine" and the Name field is "local/alpine", the alpine image is downloaded from the remote and renamed to "local/alpine".

7. Set a list of tags to include or exclude. Syncing images with a large number of tags is time consuming and uses a lot of disk space.

Procedure

1. From a terminal, create a signing script, and pass the script path as an installer parameter.

   Example:

   #!/usr/bin/env bash
   
   # pulp_container SigningService will pass the next 4 variables to the script.
   MANIFEST_PATH=$1
   FINGERPRINT="$PULP_SIGNING_KEY_FINGERPRINT"
   IMAGE_REFERENCE="$REFERENCE"
   SIGNATURE_PATH="$SIG_PATH"
   
   # Create container signature using skopeo
   skopeo standalone-sign \
     $MANIFEST_PATH \
     $IMAGE_REFERENCE \
     $FINGERPRINT \
     --output $SIGNATURE_PATH
   
   # Optionally pass the passphrase to the key if password protected.
   # --passphrase-file /path/to/key_password.txt
   
   # Check the exit status
   STATUS=$?
   if [ $STATUS -eq 0 ]; then
     echo {\"signature_path\": \"$SIGNATURE_PATH\"}
   else
     exit $STATUS
   fi

2. Review the Ansible Automation Platform installer inventory file for options for container signing that begin with automationhub_*.

   [all:vars]
   .
   .
   .
   
   automationhub_create_default_container_signing_service = True
   automationhub_container_signing_service_key = /absolute/path/to/key/to/sign
   automationhub_container_signing_service_script = /absolute/path/to/script/that/signs

3. Once installation is complete, navigate to your automation hub.
4. From the navigation panel, select Signature Keys.
5. Ensure that you have a key titled container-default, or container-anyname.

Procedure

1. Log in to automation hub.
2. From the navigation panel, select Execution Environments → Remote Registries.

3. Click Add remote registry.

   • In the Name field, enter the name of the registry where the container resides.
   • In the URL field, enter the URL of the registry where the container resides.
   • In the Username field, enter the username if necessary.
   • In the Password field, enter the password if necessary.
   • Click Save.

Procedure

1. From the navigation panel, select Execution Environments → Execution Environments.
2. Click Add execution environment.
3. Enter the name of the execution environment.
4. Optional: Enter the upstream name.
5. Under Registry, select the name of the registry from the drop-down menu.
6. Enter tags in the Add tag(s) to include field. If the field is blank, all the tags are passed. You must specify which repository specific tags to pass.

7. The remaining fields are optional:

   • Currently included tags
   • Add tag(s) to exclude
   • Currently excluded tag(s)
   • Description
8. Click Save.
9. Synchronize the image.

Procedure

1. From a terminal, log into podman, or any container client currently in use:

   > podman pull <container-name>

2. After the image is pulled, add tags (for example: latest, rc, beta, or version numbers, such as 1.0; 2.3, and so on):

   > podman tag <container-name> <server-address>/<container-name>:<tag name>

3. Sign the image after changes have been made, and push it back up to the automation hub registry:

   > podman push <server-address>/<container-name>:<tag name> --tls-verify=false --sign-by <reference to the gpg key on your local>

   If the image is not signed, it can only be pushed with any current signature embedded. Alternatively, you can use the following script to push the image without signing it:

   > podman push <server-address>/<container-name>:<tag name> --tls-verify=false

4. Once the image has been pushed, navigate to your automation hub.
5. From the navigation panel, select Execution Environments → Execution Environments.
6. To display the new execution environment, click the Refresh icon.
7. Click the name of the image to view your pushed image.

1. Click the image name to navigate to the details page.

2. Click the More Actions icon ⋮. Three options are available:

   • Use in Controller
   • Delete
   • Sign
3. Click Sign from the drop-down menu.

Procedure

1. From the navigation panel, select Signature Keys.
2. Click the More Actions icon ⋮ next to the signature that you are using.
3. Select Download key from the drop-down menu. A new window opens.
4. In the Name field, enter the name of the key.
5. Click Save.

Procedure

1. Open your terminal and use the following command:

   >  sudo <name of editor> /etc/containers/policy.json

   The file that is displayed is similar to this:

   {
     "default": [{"type": "reject"}],
     "transports": {
     	"docker": {
       	"quay.io": [{"type": "insecureAcceptAnything"}],
       	"docker.io": [{"type": "insecureAcceptAnything"}],
       	"<server-address>": [
         	{
             	    "type": "signedBy",
             	    "keyType": "GPGKeys",
             	    "keyPath": "/tmp/containersig.txt"
         	}]
     	}
     }
   }

   This file shows that neither quay.io, or docker.io will perform the verification, because the type is insecureAcceptAnything which overrides the default type of reject. However, <server-address> will perform the verification, because the parameter type is set to "signedBy".

   Note

   The only keyType currently supported is GPG keys.

2. Under the <server-address> entry, modify the keyPath <1> to include the name of your key file.

   {
       	"default": [{"type": "reject"}],
       	"transports": {
           	"docker": {
             	  "quay.io": [{"type": "insecureAcceptAnything"}],
             	  "docker.io": [{"type": "insecureAcceptAnything"}],
             	  "<server-address>": [{
                   	"type": "signedBy",
                   	"keyType": "GPGKeys",
                   	"keyPath": "/tmp/<key file name>",
                   	"signedIdentity": {
                     	  "type": "matchExact"
                       }
               	  }]
               }
       	}
   }

3. Save and close the file.