https://flyte.org logo
Join Slack
Powered by
<@UNR3C6Y4T> and <@UNW4VP36V> I have a question ab...
# flyte-support
b
@thankful-minister-83577 and @high-park-82026 I have a question about the okta setup. Flyte docs mentioned the creation of custom okta authorization server with the following custom settings - custom scopes (all and offline) and a custom auth server. I’ve experimented with it and this is what I’ve found: - the offline scope is for using refresh_token. Okta has a built-in scope for that called offline_access, which is sent back to the client if you add the Refresh Token grant to your app. This works for the default auth server. - the all scope is custom. We can create it via the default auth server. However we can create it via a custom auth server as well. Some okta org admins do not want to add custom scopes in the default auth server and keep it as vanilla as possible. I noticed that the all scope is hardcoded in the flyteadmin auth interceptor, so if we don’t pass it, okta auth does not work as expected. - custom audience is optional, meaning that since flyte requires is to create a custom auth server with custom scopes, we might as well change the audience from the default of api://default. By default okta returns an audiance equal to your clientId authenticating to Okta. We can set whatever audience we expect in the flyteadmin confing (auth.appAuth.externalAuthServer.allowedAudience) so we can use the default setting. My question is why the all scope is needed and how can we configure flyte okta auth against an okta server with only the default auth server available.
t
remind me again where you see the all scope? i feel like that’s configurable.
did you try without it?
b
Yes, I did. It does not work as it’s hardcoded in flyteadmin
i will show you
the client (flytectl/pyflyte) contacts the admin and the admin tells it what scopes to request and the idp baseurl. However the all scope (+ the offline scope) are required otherwise the admin rejects the connection with an error.
let me show you what I mean
We configure the PluginRegistry with Blanket Authorization https://github.com/flyteorg/flyte/blob/master/flyteadmin/pkg/server/service.go#L80 In the BlanketAuthorization function we check if the identity context has ScopeAll https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/interceptor.go#L21 which is currently set to “all” https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/constants.go#L24 since “all” is a custom scope we need to add it to either the default authorization server or a custom one. I successfully tested with an okta dev account and adding both “all” and “offline” scopes to the list of available scopes (so they can be requested) worked for pyflyte/flytectl. However not all Okta admins are willing to add custom scopes to the default auth server. For the userauth path (i.e. from the flyteconsole) we autoinject the “all” scope in the context created from the id_token, i.e the console/admin app using the flyteconsole okta app with openid,profile scopes. https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/token.go#L134 https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/handlers.go#L283 But for the identity context created from access_token we don’t, so unless we have the “all” scope returned from okta as we have hardcoded the check in the admin, we will fail the client with “authenticated user doesn’t have required scope” https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/handlers.go#L276 https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/token.go#L75 Why do we need this in the first place? I mean do we really need custom scopes and can we make this configurable?
@thankful-minister-83577
it all came from the original commit that introduced the oauth support by @high-park-82026
t
let me see what i can dig up
b
thanks, seem to me that “all” is a placeholder for some kind of a blanket auth, i.e. admin level access - https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/interceptor.go#L21
t
I think this is the user login path. When you login through the UI, i think the idea was that a user should have “all” the capabilities that that user’s identity is allowed to have... The idea was that in OSS we can define one of a handful of scopes (all, proj admin, user, viewer) or something and then if you configure your IDP to issue the right scopes, flyte could ultimately do some very very lightweight/entrylevel AuthZ based on these scopes. this never happened so we just have this single scope that Admin expects for all methods...
but this “all” is from Admin’s perspective, not the perspective of the rest of the idp or other applications the idp might be used for.
i think it is okay to make this configurable.
do you think you could put in a PR?
b
i am not that good with golang
but I agree that this should be configurable, cause it places a hard requirement on the idp to do custom setup in order to be able to do blanket auth. Currently not all Idp admin would like to add custom scopes, so at the very least if flyte wants to use idp as okta as authz solution, the scopes that we require should be configurable.
currently we pass the required scopes by default to the client via the flyteadmin metadata service anyway
t
mind putting in an issue?
b
ok, will do that
a
Was there an issue created for this? Curious to follow progress
t
as far as i know no ticket was made. someone made a private fork of admin i believe and made that field configurable.
was it anyone on this thread? if so, want to upstream that change?
b
I can create a ticket
41 Views
Open in Slack
PreviousNext
Powered by