https://flyte.org logo
Powered by
Title
e

Ed Fincham

02/21/2023, 4:53 PM
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) 😛artyparrot: 
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: 
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: 
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: 
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 🙂
y

Yee

02/21/2023, 7:25 PM
so you’re using flyte’s own authorization server right?
e

Ed Fincham

02/21/2023, 7:37 PM
Yeah, although in this case I'm trying to link the flytectl auth to an external IDP (azure)
y

Yee

02/21/2023, 7:52 PM
let me paste
Untitled
Untitled
that’s what we use.
h

Hampus Rosvall

02/21/2023, 8:01 PM
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 
admin:
  endpoint: dns:///endpoint
  insecure: false
  authType: Pkce
  clientId: azureIdAppRegistrationId
y

Yee

02/21/2023, 8:02 PM
yeah whether you use flyte’s authorization server or not is irrelevant to the pkce flow for flytectl.
not sure why i asked
h

Hampus Rosvall

02/21/2023, 8:02 PM
These values sets this up for us in the old deployment 
thirdPartyConfig:
          flyteClient:
            clientId: azureAppRegistrationId
            redirectUri: <http://localhost:53593/callback>
            scopes:
              - <api://azureAppRegistrationId/all>
y

Yee

02/21/2023, 8:03 PM
thank you @Hampus Rosvall
h

Hampus Rosvall

02/21/2023, 8:03 PM
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, @Yee is there a way to override the clientId for 
flyte-cli
and 
flytectl
?
y

Yee

02/21/2023, 8:08 PM
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

Hampus Rosvall

02/21/2023, 8:09 PM
the clientIds for flytepropeller and flytectl seems hardcoded in the template https://github.com/flyteorg/flyte/blob/d60c9af85a59ebb4c2265f76cb082b992078a309/charts/flyte-binary/templates/configmap.yaml#L164
y

Yee

02/21/2023, 8:10 PM
or are you saying your example is not working
h

Hampus Rosvall

02/21/2023, 8:10 PM
https://github.com/flyteorg/flyte/blob/d60c9af85a59ebb4c2265f76cb082b992078a309/charts/flyte-binary/templates/configmap.yaml#L123
y

Yee

02/21/2023, 8:10 PM
oh
it’s not configurable.
can you try changing it manually?
and we’ll add it to the chart
changing it manually just to test and confirm it works
h

Hampus Rosvall

02/21/2023, 8:11 PM
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 🙂
y

Yee

02/21/2023, 8:48 PM
the third party config is just for the endpoint that admin serves.
you still need to set the same values in the list
https://github.com/flyteorg/flyteidl/blob/master/protos/flyteidl/service/auth.proto#L86
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
e

Ed Fincham

02/21/2023, 8:51 PM
Thanks @Hampus Rosvall and @Yee. We'll do some investigating tomorrow and report back 🙂
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: 
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: 
{
  "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 🙂
t

Tyler Su

03/10/2023, 8:56 PM
@Yee could you take a look please?
h

Hampus Rosvall

03/14/2023, 11:48 AM
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.
y

Yee

03/14/2023, 3:40 PM
sorry what’s the issue?
the client ID?
if client id is still an issue, it’s been patched in the latest release https://github.com/flyteorg/flyte/blob/b82eaa5c507640a551f942de5c789198d076a491/charts/flyte-binary/values.yaml#L96
h

Hampus Rosvall

03/14/2023, 5:47 PM
right, but both that clientId as well as the one for flytectl (https://github.com/flyteorg/flyte/blob/b82eaa5c507640a551f942de5c789198d076a491/charts/flyte-binary/values.yaml#L104) is hardcoded
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: 
00000000-0000-0000-0000-000000000000
y

Yee

03/14/2023, 9:53 PM
wait what do you mean?
these are helm values
you can override them
the values.yaml file is just a default
h

Hampus Rosvall

03/14/2023, 9:54 PM
Aha, my bad!
Didn’t read thoroughly enough haha
y

Yee

03/14/2023, 10:03 PM
all good
10 Views
#ask-the-communityJoin Slack
Powered by