Ingress-nginx: 0.13.0 - auth-tls-secret is broken

Created on 19 Apr 2018  路  10Comments  路  Source: kubernetes/ingress-nginx

backend_ssl.go:48] error obtaining PEM from secret coffee-system/ingress/client-cert: error retrieving secret coffee-system/ingress/client-cert: secret coffee-system/ingress/client-cert was not found

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  namespace: coffee-system
  name: coffee-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/auth-tls-secret: "ingress/client-cert"
spec:
....
..
.

Most helpful comment

shall we ensure some extra consistency here? If yes, which format do we adopt?

Yes. This is my fault.

I think we need to support both schemes assuming the ingress namespace when the format is not 'ns/name'

All 10 comments

Reverted fec3ddc6cc117607a641932f32ef44c8e8fcb20a and built the image locally.

I don't see the error anymore.

@antoineco ping

secret coffee-system/ingress/client-cert was not found

This secret name contains a slash and is therefore invalid:

$ kubectl create secret generic 'ingress/client-cert' --from-literal='key=supersecret'    

The Secret "ingress/client-cert" is invalid: metadata.name: Invalid value: "ingress/client-cert": a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

How could it ever work?


edit: oh, right, auth-tls-secret accepts a namespace/name format

It's composed of namespace/secretName.

while auth-secret doesn't:

The secret must be created in the same namespace as the Ingress rule.

@aledbf shall we ensure some extra consistency here? If yes, which format do we adopt?

shall we ensure some extra consistency here? If yes, which format do we adopt?

Yes. This is my fault.

I think we need to support both schemes assuming the ingress namespace when the format is not 'ns/name'

Alright, I'll tokenize the result of ParseStringAnnotation() instead of always assuming ingress.Namespace (code ref).

Can this fix be released? @aledbf

@kushwiz we are planning to release a new version this Friday.

@kushwiz Looks like this didn't make it into 0.14.0?

@zivagolee this is included in 0.14.0

@aledbf ah, didn't see it in the changelog. thank you!

Was this page helpful?
0 / 5 - 0 ratings