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

Kong breaks cert-manager certificate creation #12267

Open
1 task done
jakoberpf opened this issue Dec 28, 2023 · 12 comments
Open
1 task done

Kong breaks cert-manager certificate creation #12267

jakoberpf opened this issue Dec 28, 2023 · 12 comments
Labels
area/kubernetes Issues where Kong is running on top of Kubernetes

Comments

@jakoberpf
Copy link

jakoberpf commented Dec 28, 2023

Is there an existing issue for this?

  • I have searched the existing issues

Kong version ($ kong version)

3.4

Current Behavior

When deploying kong/ingress alongside with cert-manager certificate creation failed due to cert-manager/cert-manager#5918

kubernetes ingress manifest

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: vault
  namespace: vault
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt-staging
spec:
  ingressClassName: kong
  tls:
  - hosts:
      - vault.<redacted>
    secretName: vault-cert
  rules:
  - host: vault.<redacted>
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: vault
            port:
              number: 8200

kong-controller logs

2023-12-28T17:51:33Z	error	Failed to fetch the secret (vault/gateway-cert)	{"name": "vault", "namespace": "vault", "GVK": "networking.k8s.io/v1, Kind=Ingress", "error": "resource processing failed"}

cert-manager logs

I1228 17:38:11.480947       1 trigger_controller.go:215] "cert-manager/certificates-trigger: Certificate must be re-issued" key="vault/vault-cert" reason="DoesNotExist" message="Issuing certificate as Secret does not exist"
I1228 17:38:11.481073       1 conditions.go:203] Setting lastTransitionTime for Certificate "vault-cert" condition "Issuing" to 2023-12-28 17:38:11.481064989 +0000 UTC m=+5203.127755535
I1228 17:38:11.481187       1 conditions.go:203] Setting lastTransitionTime for Certificate "vault-cert" condition "Ready" to 2023-12-28 17:38:11.48118162 +0000 UTC m=+5203.127872166
I1228 17:38:11.508725       1 controller.go:162] "cert-manager/certificates-readiness: re-queuing item due to optimistic locking on resource" key="vault/vault-cert" error="Operation cannot be fulfilled on certificates.cert-manager.io \"vault-cert\": the object has been modified; please apply your changes to the latest version and try again"
I1228 17:38:11.508842       1 conditions.go:203] Setting lastTransitionTime for Certificate "vault-cert" condition "Ready" to 2023-12-28 17:38:11.508835094 +0000 UTC m=+5203.155525641
I1228 17:38:21.707165       1 controller.go:162] "cert-manager/certificates-key-manager: re-queuing item due to optimistic locking on resource" key="vault/vault-cert" error="Operation cannot be fulfilled on certificates.cert-manager.io \"vault-cert\": the object has been modified; please apply your changes to the latest version and try again"
I1228 17:38:21.738016       1 conditions.go:263] Setting lastTransitionTime for CertificateRequest "vault-cert-1" condition "Approved" to 2023-12-28 17:38:21.737989616 +0000 UTC m=+5213.384680163
I1228 17:38:21.775055       1 conditions.go:263] Setting lastTransitionTime for CertificateRequest "vault-cert-1" condition "Ready" to 2023-12-28 17:38:21.775031464 +0000 UTC m=+5213.421722008
I1228 17:40:25.283336       1 acme.go:233] "cert-manager/certificaterequests-issuer-acme/sign: certificate issued" resource_name="vault-cert-1" resource_namespace="vault" resource_kind="CertificateRequest" resource_version="v1" related_resource_name="vault-cert-1-3054829319" related_resource_namespace="vault" related_resource_kind="Order" related_resource_version="v1"
I1228 17:40:25.283789       1 conditions.go:252] Found status change for CertificateRequest "vault-cert-1" condition "Ready": "False" -> "True"; setting lastTransitionTime to 2023-12-28 17:40:25.283779662 +0000 UTC m=+5336.930470200
E1228 17:40:35.307438       1 controller.go:167] "cert-manager/certificates-issuing: re-queuing item due to error processing" err="failed to apply secret vault/vault-cert: Patch \"https://172.20.0.1:443/api/v1/namespaces/vault/secrets/vault-cert?fieldManager=cert-manager-certificates-issuing&force=true\": context deadline exceeded" key="vault/vault-cert"
E1228 17:40:46.307796       1 controller.go:167] "cert-manager/certificates-issuing: re-queuing item due to error processing" err="failed to apply secret vault/vault-cert: Patch \"https://172.20.0.1:443/api/v1/namespaces/vault/secrets/vault-cert?fieldManager=cert-manager-certificates-issuing&force=true\": context deadline exceeded" key="vault/vault-cert"
I1228 17:40:50.644476       1 controller.go:162] "cert-manager/challenges: re-queuing item due to optimistic locking on resource" key="vault/vault-cert-1-3054829319-3717849091" error="when updating the status: Operation cannot be fulfilled on challenges.acme.cert-manager.io \"vault-cert-1-3054829319-3717849091\": the object has been modified; please apply your changes to the latest version and try again"
E1228 17:40:51.081930       1 controller.go:208] "cert-manager/challenges: challenge in work queue no longer exists" err="challenge.acme.cert-manager.io \"vault-cert-1-3054829319-3717849091\" not found"
E1228 17:40:55.645200       1 controller.go:208] "cert-manager/challenges: challenge in work queue no longer exists" err="challenge.acme.cert-manager.io \"vault-cert-1-3054829319-3717849091\" not found"
E1228 17:40:58.309581       1 controller.go:167] "cert-manager/certificates-issuing: re-queuing item due to error processing" err="failed to apply secret vault/vault-cert: Patch \"https://172.20.0.1:443/api/v1/namespaces/vault/secrets/vault-cert?fieldManager=cert-manager-certificates-issuing&force=true\": context deadline exceeded" key="vault/vault-cert"

Expected Behavior

Ingress ressources creates certificate request which creates certificate.

Steps To Reproduce

  1. Create EKS cluster
  2. Deploy cert-manager
  3. Create ClusterIssuer with dns01 challenge and route53 IRSA
  4. Deploy kong/ingress
  5. Create ingress as shown in bug report
  6. Observe cert-manager will create CertificateRequest (becomes ready) and Certificate (will stay in unready status due to "context deadline exceeded" while "applying Secret data" cert-manager/cert-manager#5918)
  7. Uninstall kong/ingress
  8. Observe that Certificate becomes ready

Anything else?

No response

@randmonkey
Copy link
Contributor

@jakoberpf According to your original issue in cert-manager repo (cert-manager/cert-manager#5918), The secret may fail on the webhook validation. So I would like to know your KIC version for further investigation.
Would you please tell me:

  • What was version of KIC?
  • How did you install KIC,Kong and certManager?

@randmonkey randmonkey added the pending author feedback Waiting for the issue author to get back to a maintainer with findings, more details, etc... label Jan 2, 2024
@jakoberpf
Copy link
Author

jakoberpf commented Jan 3, 2024

@randmonkey Thanks for the feedback. So I installed the kong/ingress chart with the version 0.10.1, which results in the controller image kong/kubernetes-ingress-controller:3.0. cert-manager chart version is v1.13.3 which is also the service version.

Both charts are install somewhat in the same time as they are part of the same terraform module in my case. I did not install the kong/kong chart. My understanding is that the kong/ingress aka. KIC is sufficient to get started?

Hope this is helpful information.

@randmonkey randmonkey removed the pending author feedback Waiting for the issue author to get back to a maintainer with findings, more details, etc... label Jan 3, 2024
@randmonkey
Copy link
Contributor

Yes, I think installing kong/ingress charts includes installing KIC (with admission webhooks) and Kong gateway. Are you using all default values?

@jakoberpf
Copy link
Author

Mostly default yes, just some service configuration...

gateway:
  proxy:
    type: NodePort
    http:
      enabled: true
      servicePort: 80
      containerPort: 8000
      nodePort: 31080

    tls:
      enabled: true
      servicePort: 443
      containerPort: 8443
      nodePort: 31443

@vibhanshu-thakur-dev
Copy link

vibhanshu-thakur-dev commented Jan 15, 2024

@jakoberpf I am facing the same issue with Kong 3.5 both in DBless and hybrid mode.

Uninstallation of Kong ingress makes all certificates available instantly. I am just passing the below values to kong helm chart:
proxy: annotations: "service.beta.kubernetes.io/aws-load-balancer-type": "nlb" "service.beta.kubernetes.io/aws-load-balancer-internal": "false" "external-dns.alpha.kubernetes.io/hostname": "domain name" "external-dns.alpha.kubernetes.io/ttl": "60" replicaCount: "2"

I have an EKS cluster with Kong 3.5 and cert manager 1.13.2

@chronolaw chronolaw added the area/kubernetes Issues where Kong is running on top of Kubernetes label Jan 17, 2024
@jakoberpf
Copy link
Author

@randmonkey can we support the investigation somehow?

@jakoberpf
Copy link
Author

jakoberpf commented Feb 21, 2024

@randmonkey sorry for bothering, but can we support in debugging or fixing this? We would love to use Kong as our solution, but this is kinda breaking any automation process.

@kaelanspatel
Copy link

kaelanspatel commented Feb 27, 2024

Also ran into this problem. On my end, this seemed to be an issue with the configuration of the KIC webhook as per: Kong/kubernetes-ingress-controller#2431.

Either fixing the issue with the ValidatingWebhook (i.e. configuration, vpc issues) or removing the secrets rule as per that issue may resolve this for you as it did for me @jakoberpf.

@jakoberpf
Copy link
Author

@kaelanspatel Thats nice, thanks. Could be a intermediary solution for us.

@chronolaw
Copy link
Contributor

@randmonkey , do you think that we have gotten a solution for this issue?

@cascadia-sati
Copy link

Also running into this, which is blocking our integration of Kong

@chrizkim
Copy link

If I'm understanding it correctly, looks like Kong/charts#1061 will address the issue when it's released, though the new flag will need to be set explicitly to true (defaults to the existing behavior)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/kubernetes Issues where Kong is running on top of Kubernetes
Projects
None yet
Development

No branches or pull requests

7 participants