search

sassoftware / viya4-deployment

This project contains Ansible code that creates a baseline in an existing Kubernetes environment for use with the SAS Viya Platform, generates the manifest for an order, and then can also deploy that order into the Kubernetes environment specified.
Apache License 2.0
70 stars 64 forks source link

(Dev Testing): feat: (IAC-1211) Add optional helm authentication for dark site OCI Container Registries #501

Open dhoucgitter opened 10 months ago

dhoucgitter commented 10 months ago

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 .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 .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 .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
mokamr commented 10 months ago

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

dhoucgitter commented 10 months ago

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?

mokamr commented 10 months ago

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.

dhoucgitter commented 10 months ago

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.

mokamr commented 10 months ago

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.

dhoucgitter commented 3 months ago

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.