aad-pod-identity VS kots

Can someone please help me with a step by step guide to perform this. https://github.com/Azure/aad-pod-identity Blog I am referring: https://trstringer.com/connect-k8s-apps-msi/

Link to my direct issue on the GitHub site: https://github.com/Azure/aad-pod-identity/discussions/1320

Q: So how am I supposed to log in to Azure so that my app can obtain tokens? A: I tell devs: For local development log in to Azure CLI with your normal user account. It has Contributor over your Dev/Test subscription and you can access secrets and configuration from their Dev/Test Key Vaults. For staging and production running in Azure (in our case Docker containers running on AKS) we use User-Assigned Managed Identity and aad-pod-identity project. This managed identity has least-privilege permissions over staging and production environments to do it's job at runtime.

The existing Azure AD Pod Identity project addresses this need. However, the Azure AD workload identity approach is simpler to use and deploy, and overcomes several limitations in Azure AD Pod Identity:

As described on the documentation, azwi is the suggested approach from now on since Azure AD Pod Identity has been (somehow) deprecated as you can read on the github repo and on the blog post here.

Unfortunately, password maintenance and rotation is a chore and has to be done in both places. There are however other things that you might want to try. 1. Kerberos authentication in pure container environments. This is something you can do on any Linux environment that is connected to AD. 2. Use AAD pod identity (https://github.com/Azure/aad-pod-identity) if running from AKS, but it is still in preview.

KOTS (by Replicated, mentioned already)

Check out https://kots.io/

We have helped clients several industries and sectors where these words either mean different things, or people who use them are thinking of different things. An appliance has meant a physical thing before it has also meant a VM.

The question you have asked includes a solution. Many client meetings start with that. This is what's called an XY problem[0], where the client says they want want Y, but that's their implementation of a solution to solve X. That may or may not be the only solution, but finding out the actual problem to be solved has never hurt me and saved a lot of time and money.

This is why we spend time defining the problem and stripping away every ounce of jargon we can, because that jargon can create a bias towards a solution that may not be optimal. For example, site-to-site VPN. Why? Gateway ? Why ? These are solutions. What's the job to be done.

Anyway... Have a look at https://www.replicated.com/ and https://kots.io/

0: https://github.com/replicatedhq/kots/pull/511