sassoftware
(Dev Testing): feat: (IAC-1211) Add optional helm authentication for dark site OCI Container Registries
Changes
In order to deploy Viya4 to an dark site cluster, application images required for DAC deployments need to be loaded into a cloud container registry as a source of deployment images, ECR is a convenient container registry to use for AWS.
DAC can use the OCI protocol to retrieve image assets from the container registry during execution of the "baseline,viya,install" tasks.
To successfully retrieve container assets via OCI, DAC needs to authenticate via helm (using helm login) to the OCI registry prior to running the helm install tasks.
Tests
| Scenario | Method | Image | DAC tags | V4_CFG_OCI_REGISTRY_URI value | Authenticate helm task executed | Task Output/Notes |
|---|---|---|---|---|---|---|
| 1 | ansible | n/a | viya,install | <account_number>.dkr.ecr.us-west-2.amazonaws.com | yes | See internal ticket |
| 2 | ansible | n/a | viya,install | none | No | |
| 3 | ansible | n/a | baseline,install | <account_number>.dkr.ecr.us-west-2.amazonaws.com | yes | See internal ticket |
| 4 | ansible | n/a | baseline,install | none | No | |
| 5 | docker | 1211-5afde66 | baseline,install | none | No | First helm chart install attempt emits 401 Unauthorized error and DAC exits |
| 6 | docker | 1211-5afde66 | baseline,install | <account_number>.dkr.ecr.us-west-2.amazonaws.com | yes | See internal ticket, All expected baseline helm charts were successfully installed from the OCI Elastic Container Registry URI provided using V4_CFG_CR_USER and V4_CFG_CR_PASSWORD for the Authenticate helm to OCI registry task |
What happens in a scenario where you have helm charts hosted on different registries other than the images? For example, if ECR is being used to hold helm charts while Nexus/Harbor/quay are being used to store images - how would we differ the authentication for the two respective registries if we only have one set of authentication variables - V4_CFG_CR_USER V4_CFG_CR_PASSWORD
Should we have something like - V4_CFG_CR_OCI_USER V4_CFG_CR_OCI_PASSWORD
What happens in a scenario where you have helm charts hosted on different registries other than the images? For example, if ECR is being used to hold helm charts while Nexus/Harbor/quay are being used to store images - how would we differ the authentication for the two respective registries if we only have one set of authentication variables - V4_CFG_CR_USER V4_CFG_CR_PASSWORD
Should we have something like - V4_CFG_CR_OCI_USER V4_CFG_CR_OCI_PASSWORD
What happens in a scenario where you have helm charts hosted on different registries other than the images? For example, if ECR is being used to hold helm charts while Nexus/Harbor/quay are being used to store images - how would we differ the authentication for the two respective registries if we only have one set of authentication variables - V4_CFG_CR_USER V4_CFG_CR_PASSWORD
Should we have something like - V4_CFG_CR_OCI_USER V4_CFG_CR_OCI_PASSWORD
@mokamr, I had originally wondered whether or not having a separate set of credentials for the CR_OCI side could be necessary but wasn't sure about the use case. If the scenario that you cite is a likely one, it would make sense to have a separate USER and PASSWORD values. One question, If your deployment VM has direct access to images in those other locations, this wouldn't be a typical dark site scenario, would it?
Yes, I agree, if your deployment VM can access helm charts from the public repo then there would be no reason for a customer to store their helm charts on some private registry. The deployment VM would be able to pull the charts locally. If the cluster is fully private with no public egress but the deployment machine has public egress then I wouldn't count it as a dark site scenario.
Yes, I agree, if your deployment VM can access helm charts from the public repo then there would be no reason for a customer to store their helm charts on some private registry. The deployment VM would be able to pull the charts locally. If the cluster is fully private with no public egress but the deployment machine has public egress then I wouldn't count it as a dark site scenario.
Hi @mokamr, thanks, so following that logic, does that mean no need for a separate OCI credential set? Just confirming.
Hi @dhoucgitter, once you set V4_CFG_OCI_REGISTRY_URI , will it be used to pull helm charts, and also be used to point baseline images to the private registry provided in the variable?
If V4_CFG_OCI_REGISTRY_URI is only intended to be used to pull helm charts for DaC, then in a scenario where the deployment client has public egress and can access the charts from the internet, it would make no sense for a customer to set V4_CFG_OCI_REGISTRY_URI let alone be worried about the separate OCI cred variables. However, the customer would still need to provide the baseline image locations to their private registry if their cluster does not have public egress.
All linter checks have passed for last weeks commit https://github.com/sassoftware/viya4-deployment/pull/501#event-12647877548 based on latest review mtg with Thomas and Sally.
Need new sanity test results for the configuration variable changes those updates introduced to verify Ansible task behavior functions as expected with Dark Site flag defined and undefined.