-
Notifications
You must be signed in to change notification settings - Fork 323
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
Conversation
Looks ok from my side :) |
@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 |
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.
5657c7e
to
365b2c2
Compare
@@ -0,0 +1,18 @@ | |||
{{- if .Values.connectInject.enabled }} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added a comment
You are right @nathancoleman, but that is the responsibility, so to speak, on the preparation of ns, not on the chart consul itself. |
…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]>
…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]>
…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]>
…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]>
Fixes #4312
Note
In order for the pull secrets to work for a
Gateway
, they must be available in any namespace that aGateway
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 forGateways
.Changes proposed in this PR
Plumb
global.imagePullSecrets
onto theServiceAccount
created for eachGateway
How I've tested this PR
Created a private registry on DockerHub for consul-dataplane, which is used by the gateway's
Deployment
Created an image pull secret for DockerHub in my K8s cluster
Set
global.imageConsulDataplane
to the private registry versionInstall using this version of the Helm chart and this build of consul-k8s-control-plane
values.yaml
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