You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The core issue is that it doesn't seem to be possible right now to render an idempotent ingress-secret. This matters because CD tools such as Argocd or Flux mandate this -- they can't compare desired state against currently deployed state if desired state changes every time its rendered. Ultimately this is a limitation of the helm implementation of htpasswd which uses the bcrypt algorithm that adds salt to the password which is why the output is always unique. Both a pro and a con. The htpasswd binary uses MD5 by default which doesn't use salt, but that's not the algorithm the helm implementation is using.
Describe the solution you'd like
This solution works but only for some ingress controllers. ingress-nginx supports an alternative format for basic-auth using the annotation nginx.ingress.kubernetes.io/auth-secret-type: auth-map (which is actually already defined) which means that each username will be stored as a key, and password as the b64enc value. This must be special handling by the ingress-nginx folks as I see no mention of it in nginx-ingress and native nginx doesn't support this which means gateway won't. An example of how this could be done: TheRealNoob@525f44b
I wasn't able to find a solution that would work for gateway given that native nginx only supports encrypted passwords that came out of the cryptography library. Not unless you got into solutions involving init containers passing the b64enc values (as above) through htpasswd. That way the k8s object is technically idempotent.
Describe alternatives you've considered
Additional context
Please let me know your thoughts on this approach -- as stated it won't work for gateway but it seems to be a harmless change allowing ingress to at least work.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The core issue is that it doesn't seem to be possible right now to render an idempotent ingress-secret. This matters because CD tools such as Argocd or Flux mandate this -- they can't compare desired state against currently deployed state if desired state changes every time its rendered. Ultimately this is a limitation of the helm implementation of htpasswd which uses the bcrypt algorithm that adds salt to the password which is why the output is always unique. Both a pro and a con. The
htpasswd
binary uses MD5 by default which doesn't use salt, but that's not the algorithm the helm implementation is using.Describe the solution you'd like
This solution works but only for some ingress controllers. ingress-nginx supports an alternative format for basic-auth using the annotation nginx.ingress.kubernetes.io/auth-secret-type: auth-map (which is actually already defined) which means that each username will be stored as a key, and password as the b64enc value. This must be special handling by the ingress-nginx folks as I see no mention of it in nginx-ingress and native nginx doesn't support this which means
gateway
won't. An example of how this could be done: TheRealNoob@525f44bI wasn't able to find a solution that would work for gateway given that native nginx only supports encrypted passwords that came out of the cryptography library. Not unless you got into solutions involving init containers passing the b64enc values (as above) through htpasswd. That way the k8s object is technically idempotent.
Describe alternatives you've considered
Additional context
Please let me know your thoughts on this approach -- as stated it won't work for gateway but it seems to be a harmless change allowing
ingress
to at least work.The text was updated successfully, but these errors were encountered: