<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/medium-vbssgzntz" -->

---
title: Medium | daily.dev
description: A practical walkthrough of migrating a Kubernetes workload on AKS from Service Principal client secrets to Azure Workload Identity Federation. The post...
canonical: https://daily.dev/posts/medium-vbssgzntz
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Medium | daily.dev
og:description: A practical walkthrough of migrating a Kubernetes workload on AKS from Service Principal client secrets to Azure Workload Identity Federation. The post...
og:url: https://daily.dev/posts/medium-vbssgzntz
og:image: https://api.daily.dev/og/posts/VBsSgznTz.png
og:image:alt: Medium
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Medium

**[Medium](https://daily.dev/sources/medium_js)** · 6 min read · 0 upvotes · 0 comments

## Summary

A practical walkthrough of migrating a Kubernetes workload on AKS from Service Principal client secrets to Azure Workload Identity Federation. The post explains why static passwords in Kubernetes Secrets are a liability, how federated identity trust works via OIDC tokens, and the key insight of attaching the Federated Identity Credential to the existing App Registration rather than creating a new Managed Identity. Includes side-by-side YAML configs for the before and after states, verification commands, and a safe three-step migration order that keeps the old password active until the new path is fully proven.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://medium.com/@janithadilsham/killing-the-password-moving-a-kubernetes-workload-from-service-principal-secrets-to-azure-workload-d456664a3277>

## Questions this post answers

### Should I create a new Managed Identity when migrating a Kubernetes workload to Azure Workload Identity Federation?

No, if the workload already has an existing App Registration and Service Principal, attach the Federated Identity Credential directly to that existing App instead of creating a new Managed Identity. This keeps the same client ID, Service Principal, and RBAC grants, avoiding the need to update pipeline variables and downstream references that already point to the original App.

_daily.dev surfaces practical migration write-ups like this for teams planning Azure identity changes._

### How do I verify that Azure Workload Identity Federation is working correctly for a pod in AKS?

Check that AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_FEDERATED_TOKEN_FILE environment variables are injected into the pod by AKS's mutating webhook, confirming the ServiceAccount token was projected. Then confirm the Secrets Store CSI driver can still read the same secret value from Key Vault as before, proving the token-to-federated-trust-to-Azure-AD-token chain works end to end.

_Engineers hardening Kubernetes identity flows can find grounded verification steps like these via daily.dev._

### What is the safe order of steps for removing a Service Principal password after adopting workload identity federation?

First add the federated credential alongside the existing password as a purely additive, zero-risk change. Next cut the workload over to workload-identity mode and verify it progressively through dev, staging, and production. Only after nothing depends on the password anymore should it be removed, as its own separate change, keeping every step independently reversible until the last one.

_Teams retiring long-lived secrets can track staged rollout patterns like this through daily.dev._

## Similar posts on daily.dev

- [I Need My CI/CD Pipeline to Access Cosmos DB Without Using a Secret](https://daily.dev/posts/i-need-my-ci-cd-pipeline-to-access-cosmos-db-without-using-a-secret-a6ied0fmf) · DevBlogs · 0 upvotes · 0 comments
- [Workload identity federation GA: Eliminate static credentials with OIDC](https://daily.dev/posts/workload-identity-federation-ga-eliminate-static-credentials-with-oidc-ekx9iis1v) · Tailscale · 0 upvotes · 0 comments
- [Jaliya's Blog: Using Microsoft Entra ID Workload Identity Federation \(WIF\) to Deploy from GitHub Actions to Azure](https://daily.dev/posts/jaliya-s-blog-using-microsoft-entra-id-workload-identity-federation-wif-to-deploy-from-github-act-gbnxmvtbs) · We Are .NET · 0 upvotes · 0 comments
- [Federated identity across the hybrid cloud using zero trust workload identity manager](https://daily.dev/posts/federated-identity-across-the-hybrid-cloud-using-zero-trust-workload-identity-manager-bulq9b2ok) · Red Hat Developer · 0 upvotes · 0 comments
- [Eliminating Long-Lived Credentials in GCP with Workload Identity Federation](https://daily.dev/posts/eliminating-long-lived-credentials-in-gcp-with-workload-identity-federation-1cwaxayl4) · InfoQ · 0 upvotes · 0 comments

---

Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#azure](https://daily.dev/tags/azure), [#authentication](https://daily.dev/tags/authentication), [#secrets-management](https://daily.dev/tags/secrets-management)

[View this post on daily.dev](https://daily.dev/posts/medium-vbssgzntz)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Medium","url":"https://daily.dev/posts/medium-vbssgzntz","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/medium-vbssgzntz"},"datePublished":"2026-07-24T19:34:13.396Z","dateModified":"2026-09-14T07:14:15.956Z","description":"A practical walkthrough of migrating a Kubernetes workload on AKS from Service Principal client secrets to Azure Workload Identity Federation. The post...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d6ab0a9a223ee01bc82d647f54feb2d2?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d6ab0a9a223ee01bc82d647f54feb2d2?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Medium","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Medium","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/medium","url":"https://daily.dev/sources/medium_js"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/medium-vbssgzntz","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"kubernetes,azure,authentication,secrets-management","timeRequired":"PT6M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Medium","item":"https://daily.dev/sources/medium_js"},{"@type":"ListItem","position":3,"name":"Medium"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/medium-vbssgzntz#faq","mainEntity":[{"@type":"Question","name":"Should I create a new Managed Identity when migrating a Kubernetes workload to Azure Workload Identity Federation?","acceptedAnswer":{"@type":"Answer","text":"No, if the workload already has an existing App Registration and Service Principal, attach the Federated Identity Credential directly to that existing App instead of creating a new Managed Identity. This keeps the same client ID, Service Principal, and RBAC grants, avoiding the need to update pipeline variables and downstream references that already point to the original App. daily.dev surfaces practical migration write-ups like this for teams planning Azure identity changes."}},{"@type":"Question","name":"How do I verify that Azure Workload Identity Federation is working correctly for a pod in AKS?","acceptedAnswer":{"@type":"Answer","text":"Check that AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_FEDERATED_TOKEN_FILE environment variables are injected into the pod by AKS's mutating webhook, confirming the ServiceAccount token was projected. Then confirm the Secrets Store CSI driver can still read the same secret value from Key Vault as before, proving the token-to-federated-trust-to-Azure-AD-token chain works end to end. Engineers hardening Kubernetes identity flows can find grounded verification steps like these via daily.dev."}},{"@type":"Question","name":"What is the safe order of steps for removing a Service Principal password after adopting workload identity federation?","acceptedAnswer":{"@type":"Answer","text":"First add the federated credential alongside the existing password as a purely additive, zero-risk change. Next cut the workload over to workload-identity mode and verify it progressively through dev, staging, and production. Only after nothing depends on the password anymore should it be removed, as its own separate change, keeping every step independently reversible until the last one. Teams retiring long-lived secrets can track staged rollout patterns like this through daily.dev."}}]}
```

