Handling of namereference prefixed by namespace.

[jbrette]

This issue is created to track what @mmb discovered in the handling of secretName transformations when used nginx.ingress related annotations (see PR

By default kustomize does not convert the secretName reference in the annotation:

nginx.ingress.kubernetes.io/auth-tls-secret: ns1/auth-tls-secret

For the deployment to work, the annotation needs to look like:

nginx.ingress.kubernetes.io/auth-tls-secret: ns1/prefix-auth-tls-secret-suffix

Here is the output:

apiVersion: v1
data:
  tls.crt: base64 encoded cert
  tls.key: base64 encoded key
kind: Secret
metadata:
  name: prefix-auth-tls-secret-suffix
  namespace: ns1
type: kubernetes.io/tls
---
apiVersion: v1
data:
  dummy: ""
kind: Secret
metadata:
  name: prefix-secret1-suffix
type: Opaque
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    ingress.kubernetes.io/auth-secret: prefix-secret1-suffix
    nginx.ingress.kubernetes.io/auth-secret: prefix-secret1-suffix
    nginx.ingress.kubernetes.io/auth-tls-secret: ns1/auth-tls-secret
  name: prefix-ingress1-suffix
spec:
  rules:
  - host: CNAME.DOMAIN.COM
    http:
      paths:
      - backend:
          serviceName: testsvc
          servicePort: 80
        path: /

[jbrette]

There is a workaround using a variable (as variable where intended to be used).
The full workaround description is available here Issue 1367

With the following input:

varReference:
- path: metadata/annotations/nginx.ingress.kubernetes.io\/auth-tls-secret
  kind: Ingress

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

namePrefix: prefix-
nameSuffix: -suffix

resources:
- ingress.yaml
- secrets.yaml

configurations:
- kustomizeconfig.yaml

vars:
- name: TLS_SECRET_NAME
  objref:
    apiVersion: v1
    kind: Secret
    name: auth-tls-secret

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress1
  annotations:
    ingress.kubernetes.io/auth-secret: secret1
    nginx.ingress.kubernetes.io/auth-secret: secret1
    nginx.ingress.kubernetes.io/auth-tls-secret: ns1/$(TLS_SECRET_NAME)
spec:
  rules:
  - host: CNAME.DOMAIN.COM
    http:
      paths:
      - path: /
        backend:
          serviceName: testsvc
          servicePort: 80

The output would is:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    ingress.kubernetes.io/auth-secret: prefix-secret1-suffix
    nginx.ingress.kubernetes.io/auth-secret: prefix-secret1-suffix
    nginx.ingress.kubernetes.io/auth-tls-secret: ns1/prefix-auth-tls-secret-suffix
  name: prefix-ingress1-suffix
spec:
  rules:
  - host: CNAME.DOMAIN.COM
    http:
      paths:
      - backend:
          serviceName: testsvc
          servicePort: 80
        path: /

[jbrette]

The namereference transformation can currently deal properly with the following structure:
simple string, configuration that fits in the namereference config:
simplefield:
xxx: somename

list of string, configuration that fits in the namereference config:
yyy:

• somename
• somename

list of map, configuration that fits in the namereference config:
zzz:

• name: somename
  namespace: ns1
• name: somename
  namespace: ns2

what @mmb did highlight is that there a structure that can't be describe efficiently yet:
ttt: ns1/somename. Does it worth it trying to put some kind of regular expression on the fieldSpec ?

Instead of

  - path: metadata/annotations/nginx.ingress.kubernetes.io\/auth-tls-secret
    kind: Ingress

  - path: metadata/annotations/nginx.ingress.kubernetes.io\/auth-tls-secret
    pattern: (namespace/)?name
    kind: Ingress

and have the pattern initialize to name

[jbrette]

We have related issues described here:

• 1323
• 1321 where ClusterRoleBinding and WebHooks are hardcoded.