push secrets management csi provider lab

[jblaaa-codes-ms]

Purpose

• Adds a lab that demonstrates how to install the CSI provider, reloader, and manage secrets in AKS

Does this introduce a breaking change?

[ ] Yes
[x ] No

Pull Request Type

What kind of change does this Pull Request introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[x ] Documentation content changes
[ ] Other... Please describe:

How to Test

• run the steps in the markdown file

[jblaaa-codes-ms]

@microsoft-github-policy-service agree

[Copilot]

Pull request overview

This PR adds comprehensive documentation for managing secrets in Azure Kubernetes Service (AKS) using the CSI Secrets Provider, Azure Key Vault, and Stakater Reloader. The lab guide walks users through deploying an AKS cluster, configuring workload identity, and demonstrating automatic secret rotation capabilities.

Key Changes:

• Added a complete lab guide for AKS secrets management using CSI provider
• Includes step-by-step instructions for setting up Key Vault, managed identity, and federated credentials
• Demonstrates secret mounting as both files and environment variables with automatic rotation

[jblaaa-codes-ms]

@copilot open a new pull request to apply changes based on the comments in this thread

[jblaaa-codes-ms]

@jblaaa-codes-ms please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree

[jblaaa-codes-ms]

@chzbrgr71 Can you review this PR and provide feedback? Thank you.

[chzbrgr71]

Thank you for your PR @jblaaa-codes-ms. We always appreciate the contributions. Hesitating to merge this because we want to avoid labs that are more repeat of our official AKS Docs. This looks similar to the doc here: https://learn.microsoft.com/en-us/azure/aks/csi-secrets-store-configuration-options?tabs=enable%2Cakvp

It does seem like the use of Reloader is a good idea and there aren't any other CNCF based tools that do the same. But we want to be sure these labs don't sound like an official Microsoft recommendation.

It would be good to incorporate this type of approach using versions for secrets. This article explains the idea. https://azureglobalblackbelts.com/2024/03/05/workload-identity-kv-csi

[swgriffith]

Thanks for contributing! Added some recommendations.

[swgriffith]

Any reason you wouldnt just enable this on initial cluster creation? It could be good to move this up, and then have a table explaining each feature you're enabling on the cluster and why (ex. KV CSI, OIDC, Workload Identity

[swgriffith]

You should be able to scope access to the specific secrets you're accessing, rather than the whole key vault. That would be more of a best practices approach.

See example here:
https://azureglobalblackbelts.com/2024/03/05/workload-identity-kv-csi

[swgriffith]

How is this role being used? If you scope access to get on the specific secret you shouldnt need this more permissive assignment.

[swgriffith]

Another good practice is to get the specific secret version ID and use that rather than as part of the secret provider class specification. That allows users to potentially maintain multiple active versions of a secret during a secret rotation. For example, you may store a blob storage key and then want to rotate the blob keys on a regular basis. By using versions you can have two active versions of a sercret and then expire one after the rollout is complete.

See example here:
https://azureglobalblackbelts.com/2024/03/05/workload-identity-kv-csi#create-the-key-vault-and-secret

[swgriffith]

It might be good to split the two yaml files into separate calls, rather than running both together. Then you can also add a short explanation about what each step is accomplishing. Don't forget that some people will have no idea what they're looking at, so more explanation is better.

Step 1: Create secret provider class
Step 2: Create deployment referencing secret provider class

[swgriffith]

Should probably add a note that reloader is a great tool for automating the reload of a deployment based on secret or configmap change, but it is one of several ways to accomplish this task, and also is not a Microsoft blessed tool. Basically want to make sure people dont see the use of reloader as an AKS 'blessed' solution...even though it is referenced in some other MSFT docs out there.