Ed Fincham
02/21/2023, 4:53 PMoidc
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 🙂Yee
02/21/2023, 7:25 PMEd Fincham
02/21/2023, 7:37 PMYee
02/21/2023, 7:52 PMHampus Rosvall
02/21/2023, 8:01 PMflytectl
app registration. The auth part of our prod config currently looks smth like
admin:
endpoint: dns:///endpoint
insecure: false
authType: Pkce
clientId: azureIdAppRegistrationId
Yee
02/21/2023, 8:02 PMHampus Rosvall
02/21/2023, 8:02 PMthirdPartyConfig:
flyteClient:
clientId: azureAppRegistrationId
redirectUri: <http://localhost:53593/callback>
scopes:
- <api://azureAppRegistrationId/all>
Yee
02/21/2023, 8:03 PMHampus Rosvall
02/21/2023, 8:03 PMflytectl
flyte-cli
and flytectl
?Yee
02/21/2023, 8:08 PMHampus Rosvall
02/21/2023, 8:09 PMYee
02/21/2023, 8:10 PMHampus Rosvall
02/21/2023, 8:10 PMYee
02/21/2023, 8:10 PMHampus Rosvall
02/21/2023, 8:11 PMflyte-core
chart which we used previously, but we are now moving to single binary deploymentflytepropeller
, flyte-cli
& flytectl
. In addition we also have a thirdPartyConfig
that also leverages the flytectl
clientId?Yee
02/21/2023, 8:48 PMinit config
Ed Fincham
02/21/2023, 8:51 PMconfiguration.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 🙂Tyler Su
03/10/2023, 8:56 PMHampus Rosvall
03/14/2023, 11:48 AMYee
03/14/2023, 3:40 PMHampus Rosvall
03/14/2023, 5:47 PM00000000-0000-0000-0000-000000000000
Yee
03/14/2023, 9:53 PMHampus Rosvall
03/14/2023, 9:54 PMYee
03/14/2023, 10:03 PM