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

GKO: ValidationWebhook panics when ManagementContext's secret ref is in a different namespace to ApiDefinition #10269

Closed
jachymsol opened this issue Jan 16, 2025 · 0 comments · Fixed by gravitee-io/gravitee-kubernetes-operator#985

Comments

@jachymsol
Copy link

Describe the bug

ValidationWebhook in Gravitee Kubernetes Operator panics when ManagementContext's secret ref is in a different namespace to ApiDefinition, even when the ManagementContext includes the namespace of the secret ref

To Reproduce

Steps to reproduce the behaviour:

  1. Run GKO
  2. Create a secret including a username and a password in namespace A
apiVersion: v1
kind: Secret
metadata:
  name: gravitee-manangement-context-secret
  namespace: A
stringData:
  username: user
  password: pass
type: Opaque
  1. Create a management context in namespace A using this secret for auth
apiVersion: gravitee.io/v1alpha1
kind: ManagementContext
metadata:
  name: management-ctx
  namespace: test
spec:
  baseUrl: <url>
  environmentId: DEFAULT
  organizationId: DEFAULT
  auth:
    secretRef:
      name: gravitee-manangement-context-secret
      namespace: A
  1. Create an ApiDefinition using this ManagementContext
apiVersion: gravitee.io/v1alpha1
kind: ApiV4Definition
metadata:
  name: api-v4-gravitee-ctx
  namespace: default
spec:
  name: API V4 using Gravitee context
  contextRef:
    namespace: test
    name: management-ctx
  <...further fields>

Expected behaviour

ValidatingWebhook should either accept or reject the resource based on its validity, providing a clear description of the potential error.

Current behaviour

The gko-controller-manager pod raises a runtime error (panic) due to dereferencing a nil pointer.
image

Useful information

This happens due to a typo on the following line: https://github.com/gravitee-io/gravitee-kubernetes-operator/blob/e135e34af26733957054cf133b4340781a271689/internal/k8s/dynamic/mctx.go#L51
Here the parentNs gets inserted into the namespace, instead of taking it from the secretRef of the Context.

Environment

What is the impacted version?
My GKO deployment is using the image graviteeio/kubernetes-operator:4.5.5

Potential impacts

Which other features may be impacted by this fix. This could be populated after fix

What are the impacted versions?

Dependencies

Link a story or other related things...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants