Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to define entrypoint command using helm chart #130

Closed
Robert-Dobry opened this issue Feb 1, 2023 · 7 comments · Fixed by #230
Closed

How to define entrypoint command using helm chart #130

Robert-Dobry opened this issue Feb 1, 2023 · 7 comments · Fixed by #230

Comments

@Robert-Dobry
Copy link

Hi, im having this trouble using oauth2-proxy helm chart. I need to setup oauth2-proxy pod so it can use secrets that I have injected into the pod using Vault agent. I know this can be done for example by overwriting entrypoint command like this:
command: ['sh', '-c', '. /vault/secrets/rest_of_the_path && /bin/oauth2-proxy']
(secret file is written like this: export OAUTH2_PROXY_... ="some_secret_value"),
but problem is that oauth2-proxy helm chart doesn't provide key command in values.yaml, and I cant find any way how to export this env variable for process that is setting up oauth2 proxy.

So my question is, how can I successfully do this export using entrypoint command or by any other way to reference client-secret or cookie-secret for oauth2-proxy config using files created by vault-agent (/vault/secrets/...).

Thanks for any answer.

@pierluigilenoci
Copy link
Contributor

pierluigilenoci commented Feb 6, 2023

Hi @Robert-Dobry,
to inject secrets into the container you can use this parameter:
https://github.com/oauth2-proxy/manifests/blob/main/helm/oauth2-proxy/values.yaml#L78

or proxyVarsAsSecrets

{{- if .Values.proxyVarsAsSecrets }}
- name: OAUTH2_PROXY_CLIENT_ID
valueFrom:
secretKeyRef:
name: {{ template "oauth2-proxy.secretName" . }}
key: client-id
- name: OAUTH2_PROXY_CLIENT_SECRET
valueFrom:
secretKeyRef:
name: {{ template "oauth2-proxy.secretName" . }}
key: client-secret
- name: OAUTH2_PROXY_COOKIE_SECRET
valueFrom:
secretKeyRef:
name: {{ template "oauth2-proxy.secretName" . }}
key: cookie-secret
{{- end }}

Changing entrypoint command doesn't seem like a viable way to me.

I'm pretty sure that with Vault it is possible to do a direct injection of environment variables.
Ref:
https://4noobies.medium.com/vault-secrets-as-environment-variables-1f0788de28b9

Does this answer your doubts?

@ArkShocer
Copy link

Hi @pierluigilenoci,
I'm having the same issue as Robert now. I want to inject via sidecar from Vault but it's not possible without changing the command. Would it be possible to add this to the helm chart? Even on the official Documentation they are doing it via the command.

@ArkShocer
Copy link

For anyone else having the same issue, this is what my values.yaml looks like when using the Bitnami OAuth2Proxy Chart:

fullnameOverride: "oauth2-proxy"

automountServiceAccountToken: true

configuration:
  content: |-
    email_domains = [ "*" ]
    provider = "oidc"
    oidc_issuer_url = "https://login.microsoftonline.com/tenant_id/v2.0"
    pass_user_headers = true
    # return authenticated user to nginx
    set_xauthrequest = true
    skip_provider_button = false
    skip_auth_regex = "^/api/\\d+/webhook/"
    provider_display_name = "Azure AD"
    cookie_expire = "1h"
    cookie_httponly = false
    cookie_secure = true
    cookie_name = "__Secure-EXAMPLE-Auth"
    cookie_domains = [".sub.example.com"]
    errors_to_info_log = true
    show_debug_on_error = true
    exclude_logging_paths = ["/ping"]
    whitelist_domains = [".sub.example.com"]
    upstreams = [ "file:///dev/null" ]

command: ["/bin/sh","-c"]
args: [". /vault/secrets/secrets.sh && oauth2-proxy --config=/bitnami/oauth2-proxy/conf/oauth2_proxy.cfg --http-address=0.0.0.0:4180"]

ingress:
  enabled: true
  ingressClassName: nginx
  path: /
  pathType: ImplementationSpecific
  hostname: auth.sub.example.com
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

podAnnotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/role: "mgmt-oauth2-proxy"
  vault.hashicorp.com/agent-inject-default-template: "json"
  vault.hashicorp.com/agent-inject-secret-oauth2-proxy.conf: "kv/mgmt/oauth2-proxy"
  vault.hashicorp.com/agent-inject-template-secrets.sh: |
    {{`{{- with secret "kv/mgmt/oauth2-proxy" -}}
    export OAUTH2_PROXY_CLIENT_ID="{{ .Data.data.OAUTH2_PROXY_CLIENT_ID }}"
    export OAUTH2_PROXY_CLIENT_SECRET="{{ .Data.data.OAUTH2_PROXY_CLIENT_SECRET }}"
    export OAUTH2_PROXY_COOKIE_SECRET="{{ .Data.data.OAUTH2_PROXY_COOKIE_SECRET }}"
    {{- end }}`}}

# Deploy redis subchart as part of oauth2-proxy
redis:
  enabled: true
  auth:
    enabled: true
  architecture: standalone

servicAccount:
  automountServiceAccountToken: true

Then for each service I want to go through the Oauth2Proxy I used the following annotations in the ingress:

  annotations:
    nginx.ingress.kubernetes.io/auth-response-headers: "X-Auth-Request-User,X-Auth-Request-Groups,X-Auth-Request-Email,X-Auth-Request-Preferred-Username"
    nginx.ingress.kubernetes.io/auth-signin: "https://auth.sub.example.com/oauth2/start?rd=https%3A%2F%2F$host$request_uri"
    nginx.ingress.kubernetes.io/auth-url: "http://oauth2-proxy.oauth2-proxy.svc.cluster.local/oauth2/auth"

@himanshujaindev
Copy link

@ArkShocer
Is this the only way to fetch oauth2 creds from the vault injector?

Did you get a chance to explore @pierluigilenoci method? I did not completely understand that way, if you did can you please explain?

@pierluigilenoci
Copy link
Contributor

@ArkShocer, could you please open a new issue?

@Robert-Dobry How did you solve it then?

@pierluigilenoci
Copy link
Contributor

@Robert-Dobry @ArkShocer can this #230 solve your problem?

@Robert-Dobry
Copy link
Author

Robert-Dobry commented Oct 1, 2024

@pierluigilenoci @ArkShocer
Hi, I solved this issue in way, that I only took the Image, and built my own helm chart around it, where I was obviously able to specify my own commands for the pods. But yes, #230 would definitely solve that problem. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants