-
Notifications
You must be signed in to change notification settings - Fork 373
Clarify Azure Key Vault reference setup and permissions #2247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Clarified how Azure Key Vault references work in Fabric, detailing storage of Key Vault URI, secret name, and user authentication context. Updated permissions requirements for access policy and Azure RBAC.
@jasonhorner : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
Learn Build status updates of commit 566520c: ✅ Validation status: passed
For more details, please refer to the build report. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR improves the documentation for Azure Key Vault references in Microsoft Fabric by clarifying the setup process and permissions requirements. The update provides more specific details about what information is stored and expands the permissions guidance to include both access policy and Azure RBAC approaches.
- Enhanced clarity on what data Fabric stores (Key Vault URI, secret name, and authentication context)
- Added comprehensive permissions guidance for both access policy-based authorization and Azure RBAC
- Emphasized that secret values are never stored or cached by Fabric
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
**Initial Setup:** | ||
Fabric records only the vault URI, secret name from your Key Vault and user auth / OAuth2.0 credential for connecting to the Azure Key Vault (AKV). You must grant your the user identity **Get** and **List** permissions in the specified AKV. Importantly, the actual secret values are never stored within Fabric. | ||
Fabric only stores the **Key Vault URI** and **secret name**, along with the user’s authentication context (OAuth 2.0 credentials) for connecting to Azure Key Vault (AKV). | ||
When using **access policy–based authorization**, you must grant the user’s identity the **Get** and **List** permissions on **secrets** in the specified Key Vault. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[nitpick] There's an inconsistency in punctuation usage. Line 24 uses an en dash (–) in 'access policy–based authorization' while standard technical writing typically uses hyphens for compound modifiers. Consider changing to 'access policy-based authorization' for consistency.
When using **access policy–based authorization**, you must grant the user’s identity the **Get** and **List** permissions on **secrets** in the specified Key Vault. | |
When using **access policy-based authorization**, you must grant the user’s identity the **Get** and **List** permissions on **secrets** in the specified Key Vault. |
Copilot uses AI. Check for mistakes.
Can you review the proposed changes? Important: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
Clarified how Azure Key Vault references work in Fabric, detailing storage of Key Vault URI, secret name, and user authentication context. Updated permissions requirements for access policy and Azure RBAC.
Thank you for contributing to Microsoft Fabric documentation
Fill out these items before submitting your pull request:
If you are working internally at Microsoft:
Provide a link to an Azure DevOps Boards work item that tracks this feature/update.
Who is your primary Skilling team contact? @mention them individually tag them and let them review the PR before signing off.
For internal Microsoft contributors, check off these quality control items as you go
1. Check the Acrolinx report: Make sure your Acrolinx Total score is above 80 minimum (higher is better) and with no spelling issues. Acrolinx ensures we are providing consistent terminology and using an appropriate voice and tone, and helps with localization.
2. Successful build with no warnings or suggestions: Review the build status to make sure all files are green (Succeeded).
3. Preview the pages:: Click each Preview URL link to view the rendered HTML pages on the review.learn.microsoft.com site to check the formatting and alignment of the page. Scan the page for overall formatting, and look at the parts you edited in detail.
4. Check the Table of Contents: If you are adding a new markdown file, make sure it is linked from the table of contents.
5. #sign-off to request PR review and merge: Once the pull request is finalized and ready to be merged, indicate so by typing
#sign-off
in a new comment in the Pull Request. If you need to cancel that sign-off, type#hold-off
instead. Signing off means the document can be published at any time. Note, this is a formatting and standards review, not a technical review.Merge and publish
#sign-off
, there is a separate PR Review team that will review the PR and describe any necessary feedback before merging.#sign-off
again. The PR Review team reviews and merges the pull request into the specified branch (usually the main branch or a release- branch).