Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[NET-10985] Fix bug where imagePullSecrets were not set up for Gateways #4316

Merged
merged 13 commits into from
Sep 27, 2024

Conversation

nathancoleman
Copy link
Member

@nathancoleman nathancoleman commented Sep 13, 2024

Fixes #4312

Note

In order for the pull secrets to work for a Gateway, they must be available in any namespace that a Gateway is deployed to. This is already the case with injected mesh sidecars if you, for example, consume consul-dataplane from a private image registry, so I have not made any special accomadations for Gateways.

Changes proposed in this PR

Plumb global.imagePullSecrets onto the ServiceAccount created for each Gateway

How I've tested this PR

  1. Created a private registry on DockerHub for consul-dataplane, which is used by the gateway's Deployment

    docker pull hashicorp/consul-dataplane:1.5.3
    docker tag hashicorp/consul-dataplane:1.5.3 <your_dockerhub_username>/consul-dataplane:1.5.3
    docker login
    docker push <your_dockerhub_username>/consul-dataplane:1.5.3
  2. Created an image pull secret for DockerHub in my K8s cluster

  3. Set global.imageConsulDataplane to the private registry version

  4. Install using this version of the Helm chart and this build of consul-k8s-control-plane

    values.yaml
    global:
      name: consul
      datacenter: dc1
      imageConsulDataplane: docker.io/<your_dockerhub_username>/consul-dataplane:1.5.3
      imageK8S: consul-k8s-control-plane:local
      imagePullSecrets:
      - name: regcred
      tls:
        enabled: true
        enableAutoEncrypt: true
      acls:
        manageSystemACLs: true
    connectInject:
      enabled: true
    kind create cluster
    make dev-docker && kind load docker-image consul-k8s-control-plane:local
    helm upgrade --install consul /path/to/consul-k8s/charts/consul --namespace consul --create-namespace --values ./values.yaml

How I expect reviewers to test this PR

See above

Checklist

@pawellegowski89
Copy link

Looks ok from my side :)

@nathancoleman
Copy link
Member Author

nathancoleman commented Sep 24, 2024

@pawellegowski89 One thing that occurred to me while testing this yesterday is that the pull secrets will need to be available in any namespace where you want to deploy a Gateway; however, this is no different from deploying mesh sidecars today if you're deploying with a consul-dataplane from a private image repo, for example.

@nathancoleman nathancoleman marked this pull request as ready for review September 24, 2024 18:43
@@ -0,0 +1,18 @@
{{- if .Values.connectInject.enabled }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need to create this is imagePullSecrets is not set?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It makes sense to gate this for now; however, in the future I am expecting this to be the place we put structured config values like this one that don't fit neatly into a flag value

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvm, I see how we handle if the image pull secrets is empty in the code, always having it results in nicer code paths

// so that it can save the proxy service id to the shared volume and boostrap Envoy with the proxy-id.
func (g Gatekeeper) initContainer(config common.HelmConfig, name, namespace string) (corev1.Container, error) {
func (g *Gatekeeper) initContainer(config common.HelmConfig, name, namespace string) (corev1.Container, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was changing this a pointer receiver to keep it consistent with the rest of the methods for the Gatekeeper?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, just an inconsistency pointed out by the editor

@@ -36,9 +36,9 @@ type initContainerCommandData struct {
LogJSON bool
}

// containerInit returns the init container spec for connect-init that polls for the service and the connect proxy service to be registered
// initContainer returns the init container spec for connect-init that polls for the service and the connect proxy service to be registered
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

)

func (g *Gatekeeper) upsertServiceAccount(ctx context.Context, gateway gwv1beta1.Gateway, config common.HelmConfig) error {
if config.AuthMethod == "" && !config.EnableOpenShift {
if config.AuthMethod == "" && !config.EnableOpenShift && len(config.ImagePullSecrets) == 0 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add a comment here about why we can't delete the service account if there are image pull secrets or maybe extract this to a function that can describe it a bit?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added a comment

.changelog/4316.txt Outdated Show resolved Hide resolved
@pawellegowski89
Copy link

@pawellegowski89 One thing that occurred to me while testing this yesterday is that the pull secrets will need to be available in any namespace where you want to deploy a Gateway; however, this is no different from deploying mesh sidecars today if you're deploying with a consul-dataplane from a private image repo, for example.

You are right @nathancoleman, but that is the responsibility, so to speak, on the preparation of ns, not on the chart consul itself.

@nathancoleman nathancoleman added the backport/1.6.x Changes are backported to 1.6 label Sep 26, 2024
@nathancoleman nathancoleman merged commit e959d33 into main Sep 27, 2024
52 of 53 checks passed
@nathancoleman nathancoleman deleted the gateway-image-pull-secrets branch September 27, 2024 16:51
nathancoleman added a commit that referenced this pull request Oct 2, 2024
…ys (#4316)

* Plumb global.imagePullSecrets through to Gateway's ServiceAccount

Since pull secrets are a list of structured objects that cannot easily be passed as a flag value to the container, this approach uses a JSON config file that is created as a ConfigMap and then mounted into the connect-injector Pod and parsed on startup.

* Leave camp cleaner than I found it

* Make path to config file configurable

* Add changelog entry

* Add note to changelog entry

* Ensure ServiceAccount is created if any image pull secrets are provided

* Add test coverage for image pull secret inclusion on gateway ServiceAccount

* Adjust note in changelog

* Add a helpful comment explaining when/why we create a ServiceAccount

* Update .changelog/4316.txt

Co-authored-by: Blake Covarrubias <[email protected]>

* Return ServiceAccount name when image pull secrets warrant it

* Improve unit tests to assert presence of ServiceAccount name on Deployment

* Copy helpful comment added elsewhere

---------

Co-authored-by: Blake Covarrubias <[email protected]>
nathancoleman added a commit that referenced this pull request Oct 2, 2024
…ys (#4316)

* Plumb global.imagePullSecrets through to Gateway's ServiceAccount

Since pull secrets are a list of structured objects that cannot easily be passed as a flag value to the container, this approach uses a JSON config file that is created as a ConfigMap and then mounted into the connect-injector Pod and parsed on startup.

* Leave camp cleaner than I found it

* Make path to config file configurable

* Add changelog entry

* Add note to changelog entry

* Ensure ServiceAccount is created if any image pull secrets are provided

* Add test coverage for image pull secret inclusion on gateway ServiceAccount

* Adjust note in changelog

* Add a helpful comment explaining when/why we create a ServiceAccount

* Update .changelog/4316.txt

Co-authored-by: Blake Covarrubias <[email protected]>

* Return ServiceAccount name when image pull secrets warrant it

* Improve unit tests to assert presence of ServiceAccount name on Deployment

* Copy helpful comment added elsewhere

---------

Co-authored-by: Blake Covarrubias <[email protected]>
nathancoleman added a commit that referenced this pull request Oct 3, 2024
…p for Gateways into release/1.4.x (#4373)

[NET-10985] Fix bug where imagePullSecrets were not set up for Gateways (#4316)

* Plumb global.imagePullSecrets through to Gateway's ServiceAccount

Since pull secrets are a list of structured objects that cannot easily be passed as a flag value to the container, this approach uses a JSON config file that is created as a ConfigMap and then mounted into the connect-injector Pod and parsed on startup.

* Leave camp cleaner than I found it

* Make path to config file configurable

* Add changelog entry

* Add note to changelog entry

* Ensure ServiceAccount is created if any image pull secrets are provided

* Add test coverage for image pull secret inclusion on gateway ServiceAccount

* Adjust note in changelog

* Add a helpful comment explaining when/why we create a ServiceAccount

* Update .changelog/4316.txt



* Return ServiceAccount name when image pull secrets warrant it

* Improve unit tests to assert presence of ServiceAccount name on Deployment

* Copy helpful comment added elsewhere

---------

Co-authored-by: Nathan Coleman <[email protected]>
Co-authored-by: Blake Covarrubias <[email protected]>
nathancoleman added a commit that referenced this pull request Oct 3, 2024
…p for Gateways into release/1.3.x (#4372)

[NET-10985] Fix bug where imagePullSecrets were not set up for Gateways (#4316)

* Plumb global.imagePullSecrets through to Gateway's ServiceAccount

Since pull secrets are a list of structured objects that cannot easily be passed as a flag value to the container, this approach uses a JSON config file that is created as a ConfigMap and then mounted into the connect-injector Pod and parsed on startup.

* Leave camp cleaner than I found it

* Make path to config file configurable

* Add changelog entry

* Add note to changelog entry

* Ensure ServiceAccount is created if any image pull secrets are provided

* Add test coverage for image pull secret inclusion on gateway ServiceAccount

* Adjust note in changelog

* Add a helpful comment explaining when/why we create a ServiceAccount

* Update .changelog/4316.txt



* Return ServiceAccount name when image pull secrets warrant it

* Improve unit tests to assert presence of ServiceAccount name on Deployment

* Copy helpful comment added elsewhere

---------

Co-authored-by: Nathan Coleman <[email protected]>
Co-authored-by: Blake Covarrubias <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CR Api Gateway - deployment service account missing imagePullSecrets
5 participants