secure query component with a sidecar

[basch255]

Requirement: The query (UI) component needs to be secured. Permissionmanagement is required.

Problem: Jaeger-Operator does not provide a solution to inject a sidecar for the query component over the jaeger crd.

Proposal: Implement some sort of additional configuration options for the jaeger crd to be able to inject a sidecar to the query component.

An idea is to expand the jaeger crd like this:

apiVersion: v1
kind: Jaeger
  metadata:
    name: jaeger
    namespace: default
  spec:
    query:
      oauthProxy:
        enabled: true
        args: {}
        image: quay.io/keycloak/keycloak-gatekeeper:10.0.0
      options: {}
      resources: {}

Issue #113 is about the same topic. An idea in the values.yaml of the Jaeger-Operator helm chart is:

jaeger:
  create: true
  spec:
    strategy: production
    query:
      oauthProxy:
        enabled: true
        image: quay.io/keycloak/keycloak-gatekeeper:10.0.0
        args:

A valid solution is already coded in a fork and a pull request will follow soon.

[jpkrohling]

Agree that this is needed. I was stuck on this for a while due to some bugs in Keycloak and it's nice that you got it working! I left a comment in the PR about the implementation, but besides that, we need some documentation as well. For instance:

1. what are the requirements to have it working? Keycloak Operator + Keycloak instance?
2. is there any specific configuration required? Do you have a link to some document showing how to configure a basic Keycloak instance? Bonus points if a simple Keycloak CR can be provided in our documentation
3. with which versions of Keycloak was it tested?

[jpkrohling]

Given the announcement on Louketo, I think we should now rethink the solution. @chlunde reported that OAuth2 Proxy can be used with Keycloak, given the appropriate things are in place.

I would prefer a generic, no-config solution, even if it means that users have to take care of a few plumbing by themselves first (like creating the required secrets).

[chlunde]

attaching a working KeycloakClient, for reference:

apiVersion: keycloak.org/v1alpha1
kind: KeycloakClient
metadata:
  labels:
    app: sso
  name: client-jaeger-ci
spec:
  client:
    clientAuthenticatorType: client-secret
    clientId: jaeger-ci
    standardFlowEnabled: true
#    secret: you can hard-code this and match it w/ what you put in oauth2-proxy, or you can get a secret-object
    rootUrl: "https://$JAEGER_QUERY_HOST.apps.$CLUSTER"
    baseUrl: "/"
    redirectUris:
      - "/oauth2/callback"
#    defaultClientScopes: # I have PR in keycloak-operator for this
#      - "profile"
#      - "email"
#      - "groups"
  realmSelector:
    matchLabels:
      app: sso

[dicolasi]

I have hit exactly the same problem. I am going to track this issue. Thanks for the effort!

[dicolasi]

here an example of side car I use in all the other services in my cluster:

 - image: quay.io/oauth2-proxy/oauth2-proxy:v6.1.1
   name: oauth2-proxy
   ports:
       - containerPort: 4180
   env:
     - name: KEYCLOAK_CLIENT_SECRET
       valueFrom:
         secretKeyRef:
           name: keycloak-client-secret-monitor-client
           key: CLIENT_SECRET
   args:
     - --provider=keycloak
     - --client-id=monitor-client
     - --client-secret=$(KEYCLOAK_CLIENT_SECRET)
     - --login-url=https://auth.{{ .Values.jxRequirements.ingress.domain  }}/auth/realms/xyz-engs/protocol/openid-connect/auth
     - --redeem-url=https://auth.{{ .Values.jxRequirements.ingress.domain  }}/auth/realms/xyz-engs/protocol/openid-connect/token
     - --validate-url=https://auth.{{ .Values.jxRequirements.ingress.domain  }}/auth/realms/xyz-engs/protocol/openid-connect/userinfo
     - --email-domain=*
     - --cookie-secure=true
     - --cookie-secret= XXXX
     - --logging-compress=true
     - --http-address=http://:4180
     - --upstream=http://127.0.0.1:9093
     - --scope=profile email roles

[esnible]

I also desire this functionality, and I want to use the same image, quay.io/oauth2-proxy/oauth2-proxy.

I see the OAuth image can be configured via viper.GetString("openshift-oauth-proxy-image"), in jaeger-operator/pkg/inject/oauth_proxy.go. I prefer the suggestion here, adding an image name override to JaegerIngressSpec or JaegerQuerySpec and JaegerAllInOneSpec.

When using image quay.io/oauth2-proxy/oauth2-proxy:v7.2.0-amd64 the config can be supplied via a flags, env vars, or a file. (The config file can be mounted from a secret via JaegerCommonSpec options, but is ignored without supplying --config /file/you/mounted in addition to mounting it.) An obvious solution to configure the sidecar is to offer security sidecar image args or env variables.

I have a security concern regarding expanding the CR to take env or arg params. Many images can be tricked into logging env vars. For example, if I (maliciously) send the client secret to the provider flag of the oauth2-proxy with something like

        env:
        - name: OAUTH2_PROXY_PROVIDER
          valueFrom:
            secretKeyRef:
              name: oidc-pass
              key: client-secret

The sidecar exposes the secret to the logs.

[2021/11/10 15:00:56] [main.go:54] invalid configuration:
  invalid setting: provider '710024e7-e71a-484e-a2aa-0f3fad561234' is not available

For that reason, instead of offering fully customizable sidecar args or envs, we might want to only expose a few explicit flag names and work with sidecar vendors to support those flag names.

Related: #1541