I’m looking for an example of programmatically inv...
# flyte-deployment
j
I’m looking for an example of programmatically invoking
flytectl register
from a CI workflow, with Flyte auth enabled. We’re on GCP/GKE. Ideally, I’d like to register files from a pod running on the GKE cluster. I think this would use the OAuth2 flow that flyte components use? Alternatively, we could run
flytectl register
from the CI runner, as this doc implies. I’d love to find an example of doing this.
our flyteadmin config
Copy code
adminServer:
    server:
      httpPort: 8088
      grpcPort: 8089
      security:
        useAuth: true
    auth:
      appAuth:
        thirdPartyConfig:
          flyteClient:
            clientId: flytectl
            redirectUri: <http://localhost:53593/callback>
            scopes:
              - offline
              - all
      authorizedUris:
        - https://{{ .Values.userSettings.hostName }}:443
        - <http://flyteadmin:80>
        - <http://flyteadmin.flyte.svc.cluster.local:80>
      userAuth:
        openId:
          baseUrl: <https://accounts.google.com>
          clientId: "{{ .Values.userSettings.oauthClientId }}"
          scopes:
            - profile
            - openid
y
flytectl is also capable of using the client credentials (username/password) flow.
let me dig up some docs in a bit.
so flyte ships by default with a client credentials application already, one that hits the Admin’s own authorization server. you can hit this by using
Copy code
flytectl --admin.authType ClientSecret --config ~/.flyte/dev-uniondemo.yaml --admin.clientId flytepropeller --admin.clientSecretLocation /tmp/p get workflow -p flytesnacks -d development
where
foobar
is in
/tmp/p
This isn’t really recommended though. It’s complicated to specify the client structure in yaml, and also you have a password effectively in cleartext stored in config (hashed), and you have to hash it in a special way (not sure will need to ask around more). Assuming you have an IDP hooked up, what you should do is just create a client credentials application (like in okta), and just call flytectl the same way.
j
i was just looking at the helm values to see how flytepropeller authenticates, here and here.
y
yeah… should probably change/disable that for real deployments
j
we do have GCP client credentials application, and we use it for user auth flow
y
is it not working?
j
it works fine for users, with a browser
y
hmm really? the browser solution should not be client credentials though
it should auth through your IDP
j
but i haven’t figured out how to automate it without a browser, using client credentials instead of pkce
user = browser + pkce
app/ci/automation - i am looking for the right commands to use client credentials flow
y
i don’t even know if this is possible with google.
we use okta internally to create these credentials.
j
yeah, that’s what i was gleaning from this doc
Google IdP does not offer an OAuth2 Authorization Server that could be used to protect external services (For example Flyte). In this case, Google offers a separate Cloud Product called Google Cloud Identity. Configuration for Cloud Identity is not included in this guide. If unavailable, setup can stop here and FlyteAdmin BuiltIn OAuth2 Authorization Server can be used instead.
y
ah yes, that was written by us?
j
your doc, yup
which is why i started looking into how flytepropeller does auth
159 Views