Options for Deploying Sample WebApp with Secrets Stored in Environment Variables

Question

As discussed in stackoverflow I'm trying to deploy my github fork of the sample PlanetaryDocs web app via a Docker container in docker hub using environment variables for the cosmos DB endpoint and account key.

Since making that post, I'm experimenting visual studio to create the docker container and then push it to dockerhub and use
az webapp create...
and
az webapp config appsettings
to create the App Service web app and, as explained in the above link, I'm having some trouble diagnosing the problem.

To get some more clues, I, thought I should experiment with some other options where I store secrets in environment variables. Is it possible to pass secrets via environment variables when using the Visual Studio 2022 deploy docker container? I tried this and did not see an opportunity to specify my secrets in the Visual Studio dialogs... Did I miss it?

OK, so what about using Visual Studio and abandoning Docker Containers all together and deploying directly the webapp to App Service. I did not see an opportunity to specify environment variable secrets there either... Did I miss it?

What other options could I investigate for deploying a sample web app with environment variables storing secrets?

Thanks

Siegfried

Mon Jan 17 2022 Morning Update:

Thank you ajkuma! I have some more question on your link on using DefaultAzureCredentials. I've done battle with this function before and could not get it to work but ended up using azure.identity.clientsecretcredential instead for the purpose of accessing blob storage inside my ASP.NET webapp running inside my Kubernetes replica set. After re-reading the DefaultAzureCredentials documentation I some more questions:

1. How does the constructor for DefaultAzureCredentials work? I'm guessing it fetches the service principal that was used to create the kubernetes cluster or App Service WebApp. Is this true? If so, that would explain why it does NOT work when running my app locally on my dev machine (where there is no app service or kubernetes cluster) and why ClientSecretCredential will work instead. After I got ClientSecretCredential working on my dev machine my WebApp would also work in the Kubernetes cluster. I wish this was move obvious from reading the documentation.
2. So previously I granted this service principal full access to my blob storage... How do I grant this same service principal full access to my cosmos DB account? I see that the CosmosDB web portal UI only accepts a managed identity... How can I grant my existing service principal full access to my CosmosDB?

Mon Jan 17 2022 Afternoon Update:

I did a

az identity create -n "mi_abc" -l westus2 -g rg_xyz  

Now I added that to my CosmosDB and it looks like the resulting JSON contains a service principal.

1. Can I create a managed identity from my existing service principal? How?
2. Now the portal web UI has no way to grant any permissions like READ_ONLY to this managed identity. How do I grant READ_ONLY to this?
3. Now if I want my kubernetes replica set webapp to have access to this cosmos DB do I have to create the Kubernetes cluster with this service principal internal to this newly created managed identity?
4. Suppose I want to access CosmosDB from my App Service Web app... Now web apps can have their own service principals too (I think)... How does this work? Do add this newly created service principal to the webApp or does that get its own separate service principal? If it gets its own service principal, what do I do with it?
5. So what does my source code look like when creating the CosmosDB client in C#? Can I call ClientSecretCredential and specify the internal service principal of my managed entity?
6. Ah! I'm thinking ClientSecretCredential might not be as secure as DefaultAzureCredentials because with ClientSecretCredential I have hardcoded the service principal and its password in the source code ... or maybe passed it in via an environment variable... So I'm thinking maybe I have defeated the main merit of managedidentities/service principals (instead of comosdb account and end points) by using ClientSecretCredential intead of DefaultAzureCredentials . Hmm... So how to I debug my code on my dev machine and still have access to CosmosDB on my dev machine and use DefaultAzureCredentials? Is there a way to tell visual studio what the service principal as that DefaultAzureCredentials is supposed to fetch for the non-existent kubernetes cluster on my dev machine?

Fri Jan 21 2022 Update:
As suggested by ajkuma, I moved these latest questions (the Mon Jan 17 2022 Updates) to how-to-use-managed-entities-and-service-principals.html.

Answer 1

SiegfriedHeintze-9929, Apologies for the delay in responding from over the weekend.

Yes, you can deploy a containerized app using Visual Studio 2022 to create a Docker image and publish it to a registry public or private.

The app setting is injected as environment variable, please see this doc -configure environment variables

Using Key Vault to store the secret is the recommended approach, see this doc.

Anyone with Subscription read access can read the app settings whereas with KV, you have to be granted specific access to the secret(s). Depending on the size of the organization, there could be a many people with read access to your subscription.