https://linen.dev logo
I am experimenting with mirrord, and I
# mirrord-help
r
I am experimenting with mirrord, and I thought i understood a lot of how it works. Where I couldn't figure out is: How to use Workload Identity with this setup? I can see the workload identity token being injected into agent pod. Though the connection to other services i.e. Azure Storage Queues fail with Client Assertion. Wondering if there is anyone who has done setup where Workload Identity/ Service Account" have been used. { "target": { "path": "pod/app-dev-charts-api-95874f8d5-b72ws", "namespace": "app-dev" }, "feature": { "env": true, "fs": "read", "network": true }, "agent": { "log_level": "info", "labels": { "app": "workload", "azure.workload.identity/use": "true" }, "namespace": "app-dev", "service_account": "sa-app-dev" }, "kube_context": "au-aks-ctspoke-npd" }
a
hey @raman_09340 , welcome 🙂 I am quite sure you don't need to add the label, since the agent uses the same env/filesystem of the target pod, so if it has such workload identity it'd inherit it.
I suspect the identity is determined in a file, that might be used locally due to some default configuration. Do you know how does the identity gets "implemented" in the pod? is it a file?
r
yes, it dumps a service account token file
which is mounted to the pod.
a
do you know it's path?
r
yes
a
can you share? I'll then provide a config file
r
/var/run/secrets/kubernetes.io/serviceaccount
a
that should be accessible from remote automatically. Can you run a short test? use the same mirrord.json then
Copy code
mirrord exec -f mirrord.json -- bash
r
in the above folder file is simply token
a
then in the bash, do
cat /var/run/secrets/kubernetes.io/serviceaccount
let me know if you get output of the remote file.
(no need to share output ofc)
r
i will install the cli..
so far i was only using the vscode extension
a
no worries, it's just easier to debug with the cli 🙂
r
yes, it dumps the token
a
great! so now we know it's more about how the app accesses it
What we see in some cases is that the SDK itself uses the local auth instead of the remote, because it has some "override" rules
r
so when app tries to access, say a cloud appliance i.e. Queue Endpoint. Is it going through the agent pod?
a
like, if you have a specific ENV it would use local auth instead of "cluster serviceaccount"
yes @raman_09340 !
are you available by any chance to share screen? It'd be probably easier to debug over a screen share 🙂
r
sure
a
r
i am on the call.