Chapter 6. Working with signed containers
6.1. Deploying your system for container signing
Execution Environments are container images used by Ansible automation controller to run jobs. This content can be downloaded to the private automation hub, and published within your organization.
Automation hub is now implementing image signing so the user can rely on better security for the EE container images.
As an Ansible Automation Platform user, you can now confirm if an EE/Container is already signed, or how to use the proper tools to sign and verify the signature yourself. This section details how to deploy your system so it is ready for container signing.
Procedure
Deploy your system with support for container signing activated.
_automation_hub: automationhub_create_default_container_signing_service: true automationhub_container_signing_service_key: _path/to/gpg.key_ automationhub_container_signing_service_script: _path/to/executable_- Navigate to automation hub.
- In the navigation pane, select Signature Keys.
- Ensure you have a key titled container-default, or container-anyname.
The 'container-default' service is created by the Ansible Automation Platform installer.
6.2. Adding containers remotely to automation hub
There are two ways to add containers to automation hub:
- Create Remotes
- Execution Environment
Procedure
To add a remote registry:
- In automation hub, click Execution Environments in the main menu pane. Two choices become available, Execution Environments, and Remote Registries.
- Click Remote Registries.
Click Add Remote Registry in the main window.
- 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.
6.3. Adding an execution environment
Procedure
- Navigate to Execution Environments.
- Enter the name of the execution environment.
- Optional: Enter the upstream name.
- Under the Registry, select the name of the registry from the drop-down menu.
- Enter tags in the Add tags to include field. If the field is left blank, all of the tags will be passed. So it is important to pass repository specific tags.
The remaining fields are optional:
- Currently included tags
- Add tag(s) to exclude
- Currently excluded tag(s)
- Description
- Groups with access
- Click Save.
- Synchronize the image.
6.4. Pushing container images from your local
Procedure
From a terminal, log into podman, or any container client currently in use.
> podman pull <__container-name__>
After the image is pulled, add tags:
> podman tag <container-name> _<server-address>_/<container-name>:<tag name>
Sign the image after changes have been made, and push it back up:
> 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.
Push the image without signing it:
> podman push _<server-address>_/<container-name>:<tag name> --tls-verify=false
- Navigate to the automation hub and click on Execution Environments if that window is not open.
- Click the Refresh icon to refresh the page to show the new execution environment.
- Click the name of the image.
In the details page, below the image name, will be displayed whether or not the image has been signed. In this case, it displays "Unsigned."
To sign the image from automation hub:
- Click the image name to open the details page.
Click the three dots in the upper right hand corner of the details page. Three options are available:
- Use in Controller
- Delete
- Sign
- Click sign from the drop-down menu.
The signing service signs the image. Once the image is signed, the status changes to "signed".
6.5. Using policies with signed images
Policies can be used by podman or other image clients to ensure the validity of the image by assigning specific policies to that signature.
6.5.1. Using podman to ensure an image is signed by a specific signature
When ensuring a signature is signed by a specific signature(s), the signature must be on your local.
Procedure
- In the navigation pane, select Signature Keys.
- Click the three dots on the right hand side of the signature that you are using.
- Select Download key from the drop-down menu. A new window opens.
- In the Name field, enter the name of the key.
- Click Save.
6.6. Configuring the client to verify signatures
Prerequsites
- The client must have sudo privileges configured to verify signatures.
Procedure
In a terminal type:
> sudo <name of editor> __/etc/containers/policy.json__
The file may look 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 shows there will be no verification from either quay.io, or docker.io since the type is insecureAcceptAnything which overrides the default type of reject. However, there will be verification from <server-address> as the parameter type has been set to "signedBy"`.
The only keyType currently supported is GPG keys.
Under the
<server-address>entry, modify thekeyPath<1> to reflect the name of your key file.{ "default": [{"type": "reject"}], "transports": { "docker": { "quay.io": [{"type": "insecureAcceptAnything}], "docker.io": [{"type": "insecureAcceptAnything}], "_<server-address>_1": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "/tmp/<key file name", 1 "signedIdentity": { "type": "remapIdentity", "prefix": "_<server-address>_", "signedPrefix": "0.0.0.0:8002" }- Save and close the file.
- Pull the file using podman, or your client of choice:
> podman pull _<server-address>_/<container-name>:<tag name> --tls-verify=false
This verifies the signature with no errors.