Using Third-Party Private Container Registries
Sometimes there is a need for a Factory’s CI services to a private third-party container registry, such as AWS’s ECR. There are two common reasons this would be needed:
- A container in
containers.git
is based on a private container image. For example, the Dockerfile hasFROM <private registry>/<container>
- A Docker Compose App references a private container image. For example, a
docker-compose.yml
with the lineimage: <private registry>/<container>
The CI needs read access to the private container image in order to construct a Target.
The Factory Definition (ci-scripts.git
) provides a way to configure this.
Configuring for CI Azure Container Registry (ACR)
The CI can be configured to use an ACR service principal with read-only access to a private ACR instance. First, the CI must be configured with the service principal’s ID and password:
$ fioctl secrets update azprincipal='<ID>:<PASSWORD>'
The Factory configuration is then updated accordingly:
# factory-config.yml
container_registries:
- type: azure
url: <YOUR REGISTRY>.azurecr.io
azure_principal_secret_name: azprincipal
Configuring Devices for ACR
Azure does not include a built-in way for devices to securely access a container registry.
The recommended approach is pushing container images from ACR to hub.foundries.io
.
Another approach is having a container image built similar to:
# containers.git <CONTAINER>/Dockerfile
FROM <YOUR REGISTRY>.azurecr.io
Then compose apps can reference the hub.foundries.io
container image.
Configuring CI for AWS ECR
CI uses the aws ecr get-login-password command to authenticate. A Factory can be configured to use this by first providing an AWS credentials file to CI:
$ fioctl secrets update aws_creds="$(cat $HOME/.aws/credentials)"
Note
Using a personal credentials file is probably not secure. An AWS admin should create an IAM account that can only pull from the container registry.
Then the configuration needs to be set.
# factory-config.yml
container_registries:
- type: aws
region: us-east-2
url: XXXXXXXXXX.dkr.ecr.us-east-2.amazonaws.com
aws_creds_secret_name: aws_creds
Configuring Devices for AWS ECR
Devices may need access to private ECR container images. While bootstrapping a project, it may be easiest to copy AWS credentials to each device. However, before going to production, it is highly recommend to use an approach that can be backed by x509 certificates. This includes the ones used for the device gateway. AWS IoT includes a mechanism for eliminating hard-coded credentials.
Another approach is to follow the procedure outlined for devices accessing the Azure Container Registry.
This wraps the container images into hub.foundries.io
.
With this setup, devices rely on the Factory authentication instead of authenticating to AWS ECR.
Configuring for CI Google Artifact Registry (GAR)
The CI can be configured to use a Google Compute Platform(GCP) service account with read-only access to a private GAR instance. A service account can be created that may only do Docker pull operations:
# Create the service account
$ NAME=<user name, eg "fio-ci">
$ gcloud iam service-accounts create ${NAME}
# Grant it minimal access to your GCP account:
$ GAR_NAME=<Registry name, eg "fio-containers">
$ LOCATION=<GCP region, eg "us-central-1">
$ PROJ_ID=<GCP project ID>
$ gcloud artifacts repositories add-iam-policy-binding \
${GAR_NAME} --location=us-central1 \
--member=serviceAccount:${NAME}@${PROJ_ID}.iam.gserviceaccount.com \
--role=roles/artifactregistry.reader
# Create the service account key file required by CI:
$ gcloud iam service-accounts keys create \
application_default_credentials.json \
--iam-account=${NAME}@${PROJ_ID}.iam.gserviceaccount.com
The service account key file created above then needs to be configured for CI:
$ fioctl secrets update gcp_creds==application_default_credentials.json
The Factory configuration is then updated accordingly:
# factory-config.yml
container_registries:
- type: gar
gar_creds_secret_name: gcp_creds
Configuring Devices for GAR
Google does not have a way to authenticate IoT core devices with the Artifact Registry. We recommend following the same approach as outlined for devices accessing the Azure Container Registry.