https://flyte.org logo
Join Slack
Powered by
<@U06RKAMK0UC> how do I make flyteadmin trust the ...
# ask-ai
c
@ancient-wolf-19325 how do I make flyteadmin trust the oidc provider certificate?
a
To make FlyteAdmin trust your OIDC provider's certificate, you need to ensure that the CA certificate used to sign the OIDC provider's certificate is available in the FlyteAdmin pod's trust store. For self-signed or custom CA certificates, you should mount the CA certificate into the FlyteAdmin container and update the system's CA trust store accordingly. This is necessary because FlyteAdmin uses standard system trust mechanisms to validate TLS connections to the OIDC provider. If the CA is not trusted, FlyteAdmin will fail to establish a secure connection to the OIDC provider, blocking authentication flows. For Kubernetes deployments, you can mount the CA certificate as a secret or config map and use an init container or startup script to append it to 
/etc/ssl/certs/ca-certificates.crt
(Debian/Ubuntu) or the appropriate trust store for your base image. This approach is referenced in the context of Flyte's sandbox and k3s, where placing extra CA certs in PEM format within a designated directory (e.g., 
~/.flyte/sandbox/ca-certificates
) adds them to the trust store, making them available to FlyteAdmin and other components that need to trust the OIDC provider's certificate (source). Would you like a step-by-step example for a specific environment or more details on updating the trust store? Sources: - https://github.com/flyteorg/flyte/pull/3609 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.
c
@ancient-wolf-19325 Give me a step by step example with flyte-core in a kubernetes context
a
It seems likely that to make FlyteAdmin (in flyte-core) trust your OIDC provider's certificate in Kubernetes, you should: 1. Create a ConfigMap or Secret with your CA certificate (in PEM format). 2. Mount the CA certificate into the FlyteAdmin pod by editing the FlyteAdmin deployment to add a volume and volumeMount. 3. Update the trust store in the FlyteAdmin container, typically by using an initContainer that appends your CA cert to 
/etc/ssl/certs/ca-certificates.crt
(Debian/Ubuntu) or the appropriate location for your image. 4. Restart FlyteAdmin so it picks up the new trust configuration. This approach is referenced in the context of Flyte's sandbox and k3s, where placing extra CA certs in a directory adds them to the trust store (source). The same method applies to Kubernetes deployments. Would you like a concrete YAML example for these steps? Sources: - https://github.com/flyteorg/flyte/pull/3609 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.
c
@ancient-wolf-19325 give me a concrete yaml example including how to use the additionalVolumes, additionalVolumeMounts and additionalContainer values of the helm chart
a
To make FlyteAdmin trust your OIDC provider's certificate using the Helm chart's 
additionalVolumes
, 
additionalVolumeMounts
, and 
additionalContainers
values, you can: 1. Create a ConfigMap with your CA certificate:
Copy code
apiVersion: v1
kind: ConfigMap
metadata:
  name: oidc-ca-cert
  namespace: flyte
data:
  oidc-ca.crt: |
    -----BEGIN CERTIFICATE-----
    ...your CA certificate...
    -----END CERTIFICATE-----
2. Add the following to your 
values.yaml
for the flyte-core Helm chart:
Copy code
flyteadmin:
  additionalVolumes:
    - name: oidc-ca-cert
      configMap:
        name: oidc-ca-cert
  additionalVolumeMounts:
    - name: oidc-ca-cert
      mountPath: /etc/oidc-ca
      readOnly: true
  additionalContainers:
    - name: update-ca-cert
      image: busybox
      command: ["/bin/sh", "-c"]
      args:
        - "cat /etc/oidc-ca/oidc-ca.crt >> /etc/ssl/certs/ca-certificates.crt"
      volumeMounts:
        - name: oidc-ca-cert
          mountPath: /etc/oidc-ca
        - name: sslcerts
          mountPath: /etc/ssl/certs/
This mounts your CA cert, and the 
update-ca-cert
container appends it to the system trust store before FlyteAdmin starts. Adjust the 
sslcerts
volume if your base image uses a different path for CA certificates. This method uses the documented Helm chart extension points for volumes, mounts, and containers (flyte-core values.yaml). Sources: - flyte-core values.yaml 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.
c
@ancient-wolf-19325 give me an example with a secret instead of a configmap
a
It seems likely that you can use a Kubernetes Secret instead of a ConfigMap for your CA certificate by creating the secret and referencing it in 
additionalVolumes
and 
additionalVolumeMounts
in your 
values.yaml
. Here’s an example: 1. Create the Secret with your CA certificate:
Copy code
apiVersion: v1
kind: Secret
metadata:
  name: oidc-ca-cert
  namespace: flyte
type: Opaque
stringData:
  oidc-ca.crt: |
    -----BEGIN CERTIFICATE-----
    ...your CA certificate...
    -----END CERTIFICATE-----
2. Reference the Secret in your `values.yaml`:
Copy code
flyteadmin:
  additionalVolumes:
    - name: oidc-ca-cert
      secret:
        secretName: oidc-ca-cert
  additionalVolumeMounts:
    - name: oidc-ca-cert
      mountPath: /etc/oidc-ca
      readOnly: true
  additionalContainers:
    - name: update-ca-cert
      image: busybox
      command: ["/bin/sh", "-c"]
      args:
        - "cat /etc/oidc-ca/oidc-ca.crt >> /etc/ssl/certs/ca-certificates.crt"
      volumeMounts:
        - name: oidc-ca-cert
          mountPath: /etc/oidc-ca
        - name: sslcerts
          mountPath: /etc/ssl/certs/
This approach is supported by the Helm chart’s documented extension points (flyte-core values.yaml). Would you like more detail or a full deployment example? Sources: - https://github.com/flyteorg/flyte/pull/3807 - https://github.com/flyteorg/flytesnacks/blob/master/examples/productionizing/productionizing/use_secrets.py 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.
c
@ancient-wolf-19325 I don't get where the volume 
sslcerts
is coming from in your example
a
The volume 
sslcerts
in the example is not automatically created by the Flyte Helm chart; you must define it yourself in 
additionalVolumes
and mount it in both the 
update-ca-cert
container and the main FlyteAdmin container. This is necessary if you want to write to 
/etc/ssl/certs/
(the system trust store), since the default root filesystem may be read-only or not shared between containers. For example, add this to your `values.yaml`:
Copy code
flyteadmin:
  additionalVolumes:
    - name: sslcerts
      emptyDir: {}
    - name: oidc-ca-cert
      secret:
        secretName: oidc-ca-cert
  additionalVolumeMounts:
    - name: sslcerts
      mountPath: /etc/ssl/certs/
    - name: oidc-ca-cert
      mountPath: /etc/oidc-ca
      readOnly: true
  additionalContainers:
    - name: update-ca-cert
      image: busybox
      command: ["/bin/sh", "-c"]
      args:
        - "cat /etc/oidc-ca/oidc-ca.crt >> /etc/ssl/certs/ca-certificates.crt"
      volumeMounts:
        - name: oidc-ca-cert
          mountPath: /etc/oidc-ca
        - name: sslcerts
          mountPath: /etc/ssl/certs/
This creates a shared, writable volume for the trust store. The 
sslcerts
volume is an 
emptyDir
, so both the init container and FlyteAdmin can access the updated CA bundle. Would you like a full deployment YAML or more explanation? Sources: - https://github.com/flyteorg/flyte/blob/master/charts/flyte-core/values-keycloak-idp-flyteclients-without-browser.yaml 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.
5 Views
Open in Slack
PreviousNext
Powered by