search

uselagoon / remote-controller

A group of controllers for handling Lagoon builds and tasks in Kubernetes or Openshift
5 stars 1 forks source link

Additional Harbor credential fixes #59

Closed shreddedbacon closed 3 years ago

shreddedbacon commented 3 years ago

closes #57 closes #58

Schnitzel commented 3 years ago

@shreddedbacon I built and pushed the image here: amazeeio/lagoon-builddeploy:pr59 unfortunately during testing I think I found an issue with the domains.

When I deleted the secret and let it recreate it created it with harbor.us2.amazee.io (no scheme), but r.Harbor.URL is with https://harbor.us2.amazee.io and so the matching doesn't work anymore and so no secret is injected into the build pod.

Maybe we need to do some url parsing and matching?

Schnitzel commented 3 years ago

oh actually I think I found the issue: the controller creates the .dockerconfigjson with https://harbor.us2.amazee.io but then during the lagoon deployment it updates the secret:

https://github.com/amazeeio/lagoon/blob/97a59c6211aea76d6a466c619043d429154fe6d4/images/kubectl-build-deploy-dind/build-deploy.sh#L12

https://github.com/amazeeio/lagoon/blob/97a59c6211aea76d6a466c619043d429154fe6d4/images/kubectl-build-deploy-dind/build-deploy.sh#L62 which then stores it without the scheme.

Schnitzel commented 3 years ago

so I think changing the kubectl-build-deploy-dind image will be hard as we have different versions running. Could we instead check with and without the schema here: https://github.com/amazeeio/lagoon-kbd/pull/59/files#diff-2c7ab529e4f550c2ff3aee023fd193b42d257ed8c1b37793613ee2917295ac9aR456 ?

Schnitzel commented 3 years ago

after some more testing I tried with --harbor-url=harbor.us2.amazee.io while technically this works, there is now the issue that some lagoon-internal-registry-secret secrets have https://harbor.us2.amazee.io inside of them and then the deployments fail, as the controller does not see the harbor url matching and does not inject a secret at all. I think we still need to do the schema parsing as it's safer (also then it doesn't really matter if --harbor-url has a schema or not)

shreddedbacon commented 3 years ago

I forgot that the build image updates this secret too, that makes this annoying.

As the controller will try and create all the secrets with the --harbor-url flag version, but then the build is now updating this to be the hostname only.

Are image pull secrets smart enough to know if https://harbor.us2.amazee.io and harbor.us2.amazee.io are the same in terms of being able to pull images from? Say the build ran and tagged/pushed harbor.us2.amazee.io/project/environment/image, and then the image secret gets updated to be harbor.us2.amazee.io as the URL.

If the robot credential rotation occurs, it will re-create the secret with https://harbor.us2.amazee.io as the URL now, will this break an image pull for this image then harbor.us2.amazee.io/project/environment/image?