namespace Transformer Does Not Update Namespace in nginx.ingress.kubernetes.io/auth-tls-secret

[GuyPaddock]

Describe the bug
#1302 added support for Kustomize to update secret names referenced by nginx.ingress.kubernetes.io/auth-tls-secret annotations when those names are affected by prefix/suffix transformers, but it does not appear that the namespace transformer is able to update these annotations.

Files that can reproduce the issue

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: some-ingress
  namespace: default
  annotations:
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-secret: "default/some-ca-cert"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "false"
    nginx.ingress.kubernetes.io/rewrite-target: "/"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - "my.host"
      secretName: my-tls-certificate
  rules:
    - host: "my.host"
      http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: some-internal-service
                port:
                  number: 8080

secrets.yaml

apiVersion: v1
kind: Secret
metadata:
  name: "some-ca-cert"
  namespace: "default"
type: Opaque
data:
  ca.crt: "--Some ca.crt--"

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ingress.yaml
  - secrets.yaml

namespace: bug-repro
namePrefix: some-prefix-

Expected output

apiVersion: v1
data:
  ca.crt: --Some ca.crt--
kind: Secret
metadata:
  name: some-prefix-some-ca-cert
  namespace: bug-repro
type: Opaque
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "false"
    nginx.ingress.kubernetes.io/auth-tls-secret: bug-repro/some-prefix-some-ca-cert
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/rewrite-target: /
  name: some-prefix-some-ingress
  namespace: bug-repro
spec:
  ingressClassName: nginx
  rules:
  - host: my.host
    http:
      paths:
      - backend:
          service:
            name: some-internal-service
            port:
              number: 8080
        path: /
        pathType: Exact
  tls:
  - hosts:
    - my.host
    secretName: my-tls-certificate

Actual output

apiVersion: v1
data:
  ca.crt: --Some ca.crt--
kind: Secret
metadata:
  name: some-prefix-some-ca-cert
  namespace: bug-repro
type: Opaque
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "false"
    nginx.ingress.kubernetes.io/auth-tls-secret: default/some-ca-cert
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/rewrite-target: /
  name: some-prefix-some-ingress
  namespace: bug-repro
spec:
  ingressClassName: nginx
  rules:
  - host: my.host
    http:
      paths:
      - backend:
          service:
            name: some-internal-service
            port:
              number: 8080
        path: /
        pathType: Exact
  tls:
  - hosts:
    - my.host
    secretName: my-tls-certificate

Kustomize version

{Version:kustomize/v4.4.1 GitCommit:b2d65ddc98e09187a8e38adc27c30bab078c1dbf BuildDate:2021-11-11T23:36:27Z GoOs:linux GoArch:amd64}

Platform

• WSL 2
• Ubuntu 20.04.3 LTS
• 5.4.91-microsoft-standard-WSL2 #1 SMP Mon Jan 25 18:39:31 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Additional context
If ingress.yaml is changed to the following:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: some-ingress
  annotations:
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-secret: "some-ca-cert"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "false"
    nginx.ingress.kubernetes.io/rewrite-target: "/"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - "my.host"
      secretName: my-tls-certificate
  rules:
    - host: "my.host"
      http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: some-internal-service
                port:
                  number: 8080

Then the output becomes the following:

apiVersion: v1
data:
  ca.crt: --Some ca.crt--
kind: Secret
metadata:
  name: some-prefix-some-ca-cert
  namespace: bug-repro
type: Opaque
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "false"
    nginx.ingress.kubernetes.io/auth-tls-secret: some-prefix-some-ca-cert
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/rewrite-target: /
  name: some-prefix-some-ingress
  namespace: bug-repro
spec:
  ingressClassName: nginx
  rules:
  - host: my.host
    http:
      paths:
      - backend:
          service:
            name: some-internal-service
            port:
              number: 8080
        path: /
        pathType: Exact
  tls:
  - hosts:
    - my.host
    secretName: my-tls-certificate

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[GuyPaddock]

/remove-lifecycle rotten

[natasha41575]

/triage accepted

It seems like the fix would be a simple update to the Namespace transformer fieldspecs. We would be happy to review a PR to resolve this issue.

[cailynse]

/assign

[yuwenma]

@natasha41575 The auth-tls-secret requires partial namespace update, I'm afraid that's not what namespace transformer can support ? related to #4457

[KnVerey]

@yuwenma is right--when we triaged this, we missed the fact that the request is to update a substring within an annotation. That is indeed something that fieldSpec-driven transformers do not support, so this is not easy to address. In this case, the transformer in question is NameReferenceTransformer. #4457 was closed because it implied unstructured edit support, which is not acceptable in Kustomize. This particular substring can be targeted structurally, but the only transformer we have that can do so right now is Replacements, specifically with its delimiter and index options. Related: #4512 (comment)

Now that I look at this again, I'm surprised we added support for this annotation in the builtin field specs in the first place, since it is related to an out-of-tree controller.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.