error loading in config from env vars

[sudo-justinwilson]

Describe the bug When replicating the quickstart and Medium tutorial, the sso-auth deployment fails to start.

To Reproduce Steps to reproduce the behavior:

1. Follow the Medium tutorial.
2. When I create the sso-auth deployment, the pod fails to start with the following error message:

   {"error":"2 error(s) decoding:\n\n* 'client[id]' expected a map, got 'string'\n* 'client[secret]' expected a map, got 'string'","level":"error","msg":"error loading in config from env vars","service":"sso-authenticator","time":"2020-05-16 10:39:39.304"}

Environment: I am running an EKS Kubernetes cluster in AWS.

Environment Variables:

        env:
          - name: GOOGLE_ADMIN_EMAIL
            valueFrom:
              secretKeyRef:
                name: google-admin-email
                key: email
          - name: GOOGLE_SERVICE_ACCOUNT_JSON
            value: /creds/service_account.json
          - name: SSO_EMAIL_DOMAIN
            value: '<mydomain>-sandbox.com'
          - name: HOST
            value: sso-auth.<mydomain>-sandbox.com
          - name: REDIRECT_URL
            value: https://sso-auth.<mydomain>-sandbox.com
          - name: PROXY_ROOT_DOMAIN
            value: <mydomain>-sandbox.com
          - name: CLIENT_ID
            valueFrom:
              secretKeyRef:
                name: google-client-id
                key: client-id
          - name: CLIENT_SECRET
            valueFrom:
              secretKeyRef:
                name: google-client-secret
                key: client-secret
          - name: PROXY_CLIENT_ID
            valueFrom:
              secretKeyRef:
                name: proxy-client-id
                key: proxy-client-id
          - name: PROXY_CLIENT_SECRET
            valueFrom:
              secretKeyRef:
                name: proxy-client-secret
                key: proxy-client-secret
          - name: COOKIE_SECRET
            valueFrom:
              secretKeyRef:
                name: auth-cookie-secret
                key: auth-cookie-secret
          - name: STATSD_HOST
            value: localhost
          - name: STATSD_PORT
            #value: "11111"
          - name: COOKIE_SECURE
            value: "false"
          - name: CLUSTER
            value: dev
          - name: VIRTUAL_HOST
            value: sso-auth.<mydomain>-sandbox.com

Google Client ID and secret formats:

apiVersion: v1
data:
client-id: <retracted>
kind: Secret
metadata:
creationTimestamp: "2020-05-14T08:45:37Z"
name: google-client-id
namespace: sso
resourceVersion: "13256458"
selfLink: /api/v1/namespaces/sso/secrets/google-client-id
uid: 4873f497-95bf-11ea-a568-0a3d94fa7918
type: Opaque
---
apiVersion: v1
data:
client-secret: <retracted>
kind: Secret
metadata:
creationTimestamp: "2020-05-14T08:46:14Z"
name: google-client-secret
namespace: sso
resourceVersion: "13256602"
selfLink: /api/v1/namespaces/sso/secrets/google-client-secret
uid: 5e8bdc47-95bf-11ea-a568-0a3d94fa7918
type: Opaque

• I have tried using both the buzzfeed/sso and buzzfeed/sso-dev images, but no luck.
• The quickstart works on my localhost (Mac laptop).

Expected behavior Expected sso-auth deployment to come up

Additional context

• I have tried using multiple docker images including buzzfeed/sso and buzzfeed/sso-dev images, but no luck.
• The quickstart works on my localhost (Mac laptop), but when I replicate the containers in a kubernetes deployment using the exact same environment variables, I get the following error:

  {"error":"invalid provider.googlequickstart config: invalid provider.type: \"\"","level":"error","msg":"error validating config","service":"sso-authenticator","time":"2020-05-16 09:13:30.561"}

[sudo-justinwilson]

I just ended up using the incubator/buzzfeed-sso helm chart..

[Jusshersmith]

Hi @sudo-justinwilson. Thanks for opening this, and sorry you've ran into some issues.

I realise you've closed this, but wanted to provide a little bit of information regardless. When running locally, are you still running SSO in a Kubernetes deployment? I would imagine this stems from some out of date variables in the SSO Kubernetes documentation.

I'll have a closer look and fix these if so.