Kubernetes uses the same ENV var "VOUCH_PORT" by default when container is named "vouch"

[vumdao]

I used AWS cognito with config

$ k get pod -l app=vouch
NAME                     READY   STATUS             RESTARTS   AGE
vouch-74f9486bcf-l8qxl   0/1     CrashLoopBackOff   6          8m2s

$ k logs vouch-74f9486bcf-l8qxl
{"level":"fatal","ts":1656954095.2000952,"msg":"envconfig.Process: assigning VOUCH_PORT to Port: converting 'tcp://172.20.247.10:9090' to type int. details: strconv.ParseInt: parsing \"tcp://172.20.247.10:9090\": invalid syntax"}

image: quay.io/vouch/vouch-proxy

No idea what's wrong here

[bnfinet]

Hi @vumdao

I'm guessing you've configured the port with a full URL but it's really hard to tell without more information.

Please read the README and supply the requested information in the manner described there. Once we have that it'll be much easier to provide support.

Cheers!

[vumdao]

@bnfinet Thanks for your reply, I did check carefully the README of how to request issue and what need to provide, so I provided my config and the only logs of the vouch pod.

I did further investigation and see that it's due to vouch service caused the step of checking availability of tcp port failed even if I define port port: 9090 or not in the config.

$ k get svc vouch
NAME    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
vouch   ClusterIP   172.20.129.189   <none>        9090/TCP   5m20s

Without the service, it started successfully but that service is required so that nginx can validate request internally

{"level":"debug","ts":1657122747.337909,"msg":"nginx will populate the variable $auth_resp_x_vouch_idp_claims_given_name"}                                                                                         {"level":"debug","ts":1657122747.337913,"msg":"cfg.RootDir: /"}
{"level":"debug","ts":1657122747.3380105,"msg":"Cfg {LogLevel:debug Listen:0.0.0.0 Port:9090 DocumentRoot: WriteTimeout:15 ReadTimeout:15 IdleTimeout:15 Domains:[stag2-vouch.vincere.io] WhiteList:[] TeamWhiteList:[] AllowAllUsers:false PublicAccess:false TLS:{Cert: Key: Profile:intermediate} JWT:{SigningMethod:HS256 MaxAge:240 Issuer:Vouch Secret:XXXXXXXX PrivateKeyFile: PublicKeyFile: Compress:true} Cookie:{Name:Vouch
2022-07-06T15:20:45.536Z        INFO    testing: true, using development console logger
2022-07-06T15:20:45.536Z        DEBUG   vouch.jwt.secret is 44 characters long                                                                                                                                     2022-07-06T15:20:45.536Z        DEBUG   vouch.session.key is 44 characters long
2022-07-06T15:20:45.536Z        INFO    jwtcache: the returned headers for a valid jwt will be cached for 20 minutes
2022-07-06T15:20:45.536Z        DEBUG   responses.Configure() attempting to parse embedded templates
{"level":"debug","ts":1657120845.5365598,"msg":"checking availability of tcp port: 0.0.0.0:9090"}
{"level":"info","ts":1657120845.6057243,"msg":"starting Vouch Proxy","version":"","buildtime":"2022-04-09T00:00:43Z","uname":"Linux","buildhost":"localhost","branch":"","semver":"","listen":"http://0.0.0.0:9090"
,"tls":false,"document_root":"","oauth.provider":"oidc"}

[vumdao]

Adding env to container fixed the issue

      containers:
        - env:
            - name: VOUCH_PORT
              value: "9090"

[bnfinet]

@vumdao I'm so glad you were able to get it working. Please do let me know if you have any further questions

[patrickdk77]

The issue is, if the container is named vouch, then the env assigned in kubernetes is VOUCH_PORT=tcp://clusterip:port
If you define it manually, it will override the default kubernetes variable.

As you can see in the example above for get svc vouch, it would add ${NAME}_PORT=tcp://${CLUSTER-IP}:${PORT}

[bnfinet]

@patrickdk77 you're pointing at a naming conflict/overlap for environmental variables between VP and kubernetes running vouch?

That seems like a different issue. Could you please open a new issue to address that problem.

[patrickdk77]

I'm not sure how it is a different issue, the original issue was about the env overlap in kubernetes, and my response was about the same, since why it happens, or when you need or why you need to override it was not addressed.

[bnfinet]

@patrickdk77 if that's the case then you're helping me to better understand the original issue

I was under the impression that it was a configuration issue and that the container required the additional env var.

I think I see it better now.

[bnfinet]

@patrickdk77 what do you think the correct behavior of VP should be here?

Is there a way to detect a Kubernetes cluster from within the container?

[patrickdk77]

The only way I know to detect it inside the container is looking for env KUBERNETES_PORT, but not sure if that is foolproof.

I would likely just parse VOUCH_PORT, and if it is invalid, throw the error as currently done, and ignore the value and use the default it would have used instead. If it doesn't work, they can see it in the logs, and if it does work, it can also be a hint if they do look at the logs and see it.

[bnfinet]

During config sanity check, it'd probably be nice if VP determined if VOUCH_PORT was not a number and then check if KUBERNETES_PORT was set and offer a helpful warning before failure.

I feel like anything more than that changes the expected (and currently deployed) behavior of VP's VOUCH_PORT env var.

[bnfinet]

@patrickdk77 thanks for clarifying my understanding of the problem.

PR is most welcome