https://flyte.org logo
Join Slack
Powered by
Hey everyone, I'm trying to set up auth with the ...
# flyte-support
s
Hey everyone, I'm trying to set up auth with the flyte binary and while I've had some success (with help from you guys 🙂), I'm still running into a few issues. In particular, I'm using Azure as the OIDC provider and have everything working in the below snippet. This is one Azure application and the 
oidc
section here allows me to access the UI via an ingress (defined via the chart) 🦜
Copy code
auth:
    enabled: true
    oidc:
      baseUrl: <https://signin.hosted.unionai.cloud/oauth2/default>
      clientId: <IDP_CLIENT_ID>
      clientSecret: <IDP_CLIENT_SECRET>
    internal:
      clientSecret: <CC_PASSWD>
      clientSecretHash: <HASHED_CC_PASSWD>
I also have another azure application which, in the pre-flyte-binary setup that I am migrating from, was used to populate the values here:
Copy code
configmap:
  adminServer:
   auth:
     ...
     appAuth:
       ...
       thirdPartyConfig:
         flyteClient:
           clientId: XXX
           redirectUri: <http://localhost:53593/callback>
           scopes:
             - XXX
In the flyte-binary chart, editing these values isn't an option but if you check out the 
flyte-backend-flyte-binary-config
you can see some hardcoded values:
Copy code
thirdPartyConfig:
  flyteClient:
    clientId: flytectl
    redirectUri: <http://localhost:53593/callback>
    scopes:
    - offline
    - all
Is it possible to overwrite these defaults? I tried the following in my flyte-binary chart values:
Copy code
configuration:
  inline:
    auth:
      appAuth:
        thirdPartyConfig:
          flyteClient:
            clientId: XXX
            redirectUri: <http://localhost:53593/callback>
            scopes:
              - XXX
But I don't think this worked. Sorry for the long post, but any idea how I can override hard-coded 
thirdPartyConfig
values in the helm chart? Thanks a lot for all the continued help 🙂
To give a tl;dr: I need to use the flytectl app for Pkce Auth flow and don't know where to add this client ID 🙂
t
so you’re using flyte’s own authorization server right?
s
Yeah, although in this case I'm trying to link the flytectl auth to an external IDP (azure)
t
let me paste
Untitled
Untitled
that’s what we use.
h
Jumping in here, in our current set up (not using a single-binary) we don’t use flyte’s own authorization server but leverage proof key of code auth flow in the 
flytectl
app registration. The auth part of our prod config currently looks smth like
Copy code
admin:
  endpoint: dns:///endpoint
  insecure: false
  authType: Pkce
  clientId: azureIdAppRegistrationId
t
yeah whether you use flyte’s authorization server or not is irrelevant to the pkce flow for flytectl.
not sure why i asked
h
These values sets this up for us in the old deployment
Copy code
thirdPartyConfig:
          flyteClient:
            clientId: azureAppRegistrationId
            redirectUri: <http://localhost:53593/callback>
            scopes:
              - <api://azureAppRegistrationId/all>
✅ 1
🙏 1
t
thank you @helpful-crowd-74546
h
So basically we just need to port what is stated above to the single binary deployment
To clarify, I am working with Ed. But I set up the auth for our current deployment and just wanted to clarify what use currently.
The difference is that in the old values we could override the clientId for the flytectl app, whereas here the clientId seems hardcoded to 
flytectl
Thus, @thankful-minister-83577 is there a way to override the clientId for 
flyte-cli
and 
flytectl
?
t
flyte-cli is on the decline…
we’re trying to deprecate it
flytectl - sure. you can set it in the config
should work, let us know if it doesn’t
h
t
or are you saying your example is not working
h
t
oh
it’s not configurable.
can you try changing it manually?
👍 1
and we’ll add it to the chart
changing it manually just to test and confirm it works
h
My example works for 
flyte-core
chart which we used previously, but we are now moving to single binary deployment
I guess lots of authorization servers e.g., Okta uses the registered app name as identifier. However, Azure app registrations are identified by a unique id rather than name
In the auth config set up we should configure three apps, one for admin, propeller and ctl. How does these map to the auth config in the single binary template? There are three static clients defined i.e., 
flytepropeller
, 
flyte-cli
& 
flytectl
. In addition we also have a 
thirdPartyConfig
that also leverages the 
flytectl
clientId?
We’ll try to play around with the config map to see if we can port what we have configured currently to the single binary deployment! Thanks for the help, will get back how it goes 🙂
t
the third party config is just for the endpoint that admin serves.
you still need to set the same values in the list
that endpoint is how flytectl is able to 
init config
yeah let us know
thank you
we are happy to change the helm chart to support whatever customization makes sense
s
Thanks @helpful-crowd-74546 and @thankful-minister-83577. We'll do some investigating tomorrow and report back 🙂
thx 2
Hey all, Just wanted to update you: we're going to switch back to the original flyte version. As I understand it, we have three auth use-cases in flyte: • Authenticated endpoint for console access (via OIDC) • Intra-component auth to the admin control plane (via client secret/hash) • Flytectl access The first two appear to be working, but we've really struggled to get the last to work. Currently, we have a log level of 6 in our 
configuration.logging.level
and a log level of 15 in the 
~/.flyte/config
, which looks like this:
Copy code
admin:
  endpoint: dns:///$ENDPOINT
  insecure: false
  authType: Pkce
  clientId: $AZUREAD_APP_ID
logger:
  show-source: true
  level: 15
storage:
  type: stow
  stow:
    kind: s3
    config:
      auth_type: iam
      region: $REGION
  container: "$CONTAINER"
Seems like the issue is that the client ID in the binary helm chart is hardcoded, which we edited in the 
flyte-backend-flyte-binary-config
config-map to match our 
~/.flyte/config
value as well as update the scopes (all this matches our original flyte helm chart values). When running any command with flytectl, we get hit with the following error:
Copy code
{
  "json": {
    "src": "main.go:13"
  },
  "level": "error",
  "msg": "Connection Info: [Endpoint: dns:///$ENDPOINT, InsecureConnection?: false, AuthMode: Pkce]: rpc error: code = Unknown desc = unexpected HTTP status code received from server: 464 (); malformed header: missing HTTP content-type",
  "ts": "2023-02-27T09:38:39+01:00"
}
No logs for this request in the deployment so it's very hard to figure out what's gone wrong. As I mentioned earlier, our plan is to revert back to the original flyte helm chart but nevertheless, it would be really helpful to get some insight as to what is wrong with the current configuration 🙂
w
@thankful-minister-83577 could you take a look please?
h
The issue is that we don’t really support Azure as IdP for the binary deployment. The client ids are not the name of the app in Azure case, rather a uuid. Moreover, the scopes needs to be modified for the authentication to work in the flytectl scenario. Happy to discuss the modifications required and get it into docs with someone for your end.
t
sorry what’s the issue?
the client ID?
h
this seems to work in e.g., okta, however, in azure the client id for the app registration is defined by uuid
meaning in our case the clientId would be smth like:
Copy code
00000000-0000-0000-0000-000000000000
t
wait what do you mean?
these are helm values
you can override them
the values.yaml file is just a default
h
Aha, my bad!
Didn’t read thoroughly enough haha
t
all good
403 Views
Open in Slack
PreviousNext
Powered by