In keeping with the Cake platform security posture, all of the services that run within the Cake cluster are protected by Dex and Istio. Together these services ensure that any requests for non-public services that enter the cluster have a valid JWT issued by Dex which coincides with an OIDC user or a pre-configured machine-to-machine account protected by a known shared secret.
However, there are cases where there are some services that expose their own authentication which conflicts with the Cake security requirements. We have implemented a workaround for this that allows end users to access internal services that expose their own authentication (particularly in the case of APIs) by adding an additional header X-Cake-Authorization to requests so that we can ensure that the request is coming from a valid OIDC user.
Currently, this workaround is implemented for Label Studio which permits access to the Label Studio API.
Here’s an example using OAuth2c
#/usr/bin/env bash
## This script is invoked with 2 parameters, the name of the cluster and the url of the Dex instance, eg: script.sh my-cake-cluster <https://cake.example.com/dex>
## This script assumes that you have access to your cluster's secret manager which contains the cake-public-client's client_secret.
CLUSTER_NAME='$1'
CLIENT_SECRET=$(aws secretsmanager get-secret-value --secret-id kflow-platform/$CLUSTER_NAME/dex-cake-public-client | jq '.SecretString|fromjson|.client_secret' -r)
$(oauth2c $2 --client-id cake-public-client --client-secret $CLIENT_SECRET --response-types code --scopes openid,email,profile --grant-type authorization_code --auth-method client_secret_post --response-mode form_post) | jq -r '.access_token'
The result is an access token that can then be added to an X-Cake-Authorization header, eg:
curl -X GET <https://cake.example.com/labelstudio/api/projects/> -H 'Authorization: Token LABELSTUDIO_TOKEN' -H 'X-Cake-Authorization: ACCESS TOKEN FROM ABOVE'
Any OAuth2 compliant client implementation can be used.