docs(azure_blob): add managed identity and workload identity auth#2381
docs(azure_blob): add managed identity and workload identity auth#2381temporaer wants to merge 5 commits intofluent:masterfrom
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughExtended Azure Blob output docs to add new authentication modes ( Changes
Sequence Diagram(s)sequenceDiagram
participant Pod as Pod / Workload
participant FluentBit as Fluent Bit
participant TokenFile as Token File / ServiceAccount
participant IMDS as Azure IMDS / MSI Endpoint
participant Blob as Azure Blob Storage
Pod->>FluentBit: local log ingestion
FluentBit->>TokenFile: read workload_identity_token_file (if configured)
alt workload identity (token file)
TokenFile-->>FluentBit: return OIDC token
else managed identity flow
FluentBit->>IMDS: request access token (client_id or system)
IMDS-->>FluentBit: return access token
end
FluentBit->>Blob: authenticate using token/key/SAS and upload blobs
Blob-->>FluentBit: respond with success/failure
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan for PR comments
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
bfff2ab to
1a1d28c
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
pipeline/outputs/azure_blob.md (1)
235-296: Workload Identity section is well-documented.The Workload Identity configuration is properly explained with:
- Clear context about AKS and federated service accounts
- Complete examples showing all required parameters (
client_id,tenant_id)- Helpful note about overriding the token file path for non-standard configurations
The examples correctly demonstrate the workload identity authentication pattern for AKS environments.
Optional enhancement: Consider briefly mentioning that workload identity requires proper AKS cluster setup and service account federation (perhaps with a link to Azure documentation), though this may be beyond the scope of Fluent Bit-specific documentation.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pipeline/outputs/azure_blob.md` around lines 235 - 296, Add a brief one-sentence note under the Workload Identity section (near the fluent-bit.yaml / fluent-bit.conf examples) stating that AKS must have service account federation configured for workload identity to work and include a short link to the Azure AD workload identity docs (for example, Azure docs on Workload Identity Federation) so readers can follow cluster setup steps; reference the examples and the workload_identity_token_file, client_id and tenant_id options so the note appears adjacent to those configuration snippets.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@pipeline/outputs/azure_blob.md`:
- Around line 235-296: Add a brief one-sentence note under the Workload Identity
section (near the fluent-bit.yaml / fluent-bit.conf examples) stating that AKS
must have service account federation configured for workload identity to work
and include a short link to the Azure AD workload identity docs (for example,
Azure docs on Workload Identity Federation) so readers can follow cluster setup
steps; reference the examples and the workload_identity_token_file, client_id
and tenant_id options so the note appears adjacent to those configuration
snippets.
|
@temporaer thanks for the PR, but looks like some linting issues need fixing. |
99db38b to
87c65c2
Compare
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
pipeline/outputs/azure_blob.md (2)
75-75:⚠️ Potential issue | 🟡 MinorPre-existing typo:
azure_blogshould beazure_blob.The output plugin name is misspelled as
azure_bloginstead ofazure_blob. While this is a pre-existing issue (not introduced by this PR), it should be corrected to prevent user confusion.✏️ Suggested fix
- - name: azure_blog + - name: azure_blob🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pipeline/outputs/azure_blob.md` at line 75, Update the misspelled output plugin name by replacing the identifier "azure_blog" with the correct "azure_blob" wherever it appears (notably the plugin name declaration shown as azure_blog) so documentation and configuration match the intended Azure Blob storage naming; ensure any references, examples, and headings using azure_blog are updated to azure_blob for consistency.
342-342:⚠️ Potential issue | 🟡 MinorPre-existing typo:
azure_blogshould beazure_blob.The output plugin name is misspelled as
azure_bloginstead ofazure_blob. While this is a pre-existing issue (not introduced by this PR), it should be corrected to prevent user confusion.✏️ Suggested fix
- - name: azure_blog + - name: azure_blob🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pipeline/outputs/azure_blob.md` at line 342, The output plugin name is misspelled: replace the incorrect identifier "azure_blog" with the correct name "azure_blob" wherever it appears (e.g., the plugin declaration or configuration keys) so references match the actual Azure Blob plugin; search for occurrences of "azure_blog" and rename them to "azure_blob" ensuring comments and docs are updated consistently.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@pipeline/outputs/azure_blob.md`:
- Line 75: Update the misspelled output plugin name by replacing the identifier
"azure_blog" with the correct "azure_blob" wherever it appears (notably the
plugin name declaration shown as azure_blog) so documentation and configuration
match the intended Azure Blob storage naming; ensure any references, examples,
and headings using azure_blog are updated to azure_blob for consistency.
- Line 342: The output plugin name is misspelled: replace the incorrect
identifier "azure_blog" with the correct name "azure_blob" wherever it appears
(e.g., the plugin declaration or configuration keys) so references match the
actual Azure Blob plugin; search for occurrences of "azure_blog" and rename them
to "azure_blob" ensuring comments and docs are updated consistently.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pipeline/outputs/azure_blob.md`:
- Line 237: Replace the outdated term "Azure AD" with the current official name
"Microsoft Entra ID" in the sentence that reads "Azure Workload Identity lets
pods in Azure Kubernetes Service (AKS) authenticate to Azure Blob Storage using
a Kubernetes service account federated with Azure AD" so the phrase now uses
"Microsoft Entra ID"; ensure any other occurrences of the exact token "Azure AD"
in this document are updated consistently to "Microsoft Entra ID".
|
@eschabell, sorry, i didn't notice. Should be fixed now! |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pipeline/outputs/azure_blob.md`:
- Around line 117-120: Update the "Configuration for managed identity" section
and the workload identity section to add a required RBAC roles subsection: state
that users must assign one of the Azure Storage RBAC roles (Storage Blob Data
Reader, Storage Blob Data Contributor, or Owner) to the managed identity or
federated/client identity at the storage account or container scope before
attempting access; include a short note on least-privilege guidance (prefer
Reader/Contributor as appropriate) and a brief example sentence on where to
assign these roles in the Azure Portal/CLI, referencing the headings
"Configuration for managed identity" and the workload/federated identity
paragraph so reviewers can locate the additions.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 66eaba85-bda7-4085-b650-2413eb8a96fc
📒 Files selected for processing (1)
pipeline/outputs/azure_blob.md
|
@temporaer ongoing updates for upcoming release have hit this plugin doc page, so it's caused a conflict on your end (rebase to pull them into this file). Sorry for the trouble. |
Document new auth_type values (managed_identity, workload_identity) and related configuration parameters (client_id, tenant_id, workload_identity_token_file) with configuration examples. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Hannes Schulz <Hannes.Schulz@microsoft.com>
- Use sentence-style capitalization in headings - Replace 'file path' with 'path' per FluentBit.WordList rule Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Hannes Schulz <Hannes.Schulz@microsoft.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Signed-off-by: Hannes Schulz <hannes.schulz@microsoft.com> Signed-off-by: Hannes Schulz <Hannes.Schulz@microsoft.com>
509f266 to
160d34f
Compare
|
@eschabell , no problem. Done! |
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (4)
pipeline/outputs/azure_blob.md (4)
221-241:⚠️ Potential issue | 🟡 MinorFix case inconsistency in fluent-bit.conf example.
Apply the same Title_Case correction as noted in the system-assigned managed identity example above.
🔧 Proposed fix
[SERVICE] - flush 1 - log_level info + Flush 1 + Log_Level info [INPUT] - name dummy - dummy {"name": "Fluent Bit", "year": 2024} - samples 1 - tag var.log.containers.app-default-96cbdef2340.log + Name dummy + Dummy {"name": "Fluent Bit", "year": 2024} + Samples 1 + Tag var.log.containers.app-default-96cbdef2340.logAs per coding guidelines, classic fluent-bit.conf examples use Title_Case for plugin-specific keys.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pipeline/outputs/azure_blob.md` around lines 221 - 241, Update the fluent-bit.conf example in the [OUTPUT] azure_blob block to use Title_Case for plugin-specific keys (e.g., change account_name, auth_type, client_id, container_name, auto_create_container, tls, match, name to Account_Name, Auth_Type, Client_Id, Container_Name, Auto_Create_Container, TLS, Match, Name) so the example matches the Title_Case style used in the system-assigned managed identity sample; edit the azure_blob [OUTPUT] stanza (keys: name, match, account_name, auth_type, client_id, container_name, auto_create_container, tls) accordingly.
280-301:⚠️ Potential issue | 🟡 MinorFix case inconsistency in fluent-bit.conf example.
Apply the same Title_Case correction as noted in the previous managed identity examples.
🔧 Proposed fix
[SERVICE] - flush 1 - log_level info + Flush 1 + Log_Level info [INPUT] - name dummy - dummy {"name": "Fluent Bit", "year": 2024} - samples 1 - tag var.log.containers.app-default-96cbdef2340.log + Name dummy + Dummy {"name": "Fluent Bit", "year": 2024} + Samples 1 + Tag var.log.containers.app-default-96cbdef2340.logAs per coding guidelines, classic fluent-bit.conf examples use Title_Case for plugin-specific keys.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pipeline/outputs/azure_blob.md` around lines 280 - 301, The fluent-bit example uses snake_case plugin keys; change plugin-specific keys in the [OUTPUT] azure_blob block (e.g., account_name, auth_type, client_id, tenant_id, container_name, auto_create_container, tls, match, name) to Title_Case as in other managed-identity examples (e.g., Account_Name, Auth_Type, Client_ID, Tenant_ID, Container_Name, Auto_Create_Container, TLS, Match, Name) so the example matches the project's fluent-bit style; update only the keys' casing and keep their values unchanged.
246-249:⚠️ Potential issue | 🟡 MinorAdd required RBAC role configuration guidance for workload identity.
Similar to managed identity, workload identity requires Azure RBAC role assignment. The federated credential (linked to the Kubernetes service account) must be assigned a Storage Blob Data role at the storage account or container scope before it can access blob data.
📋 Suggested addition
### Configuration for workload identity Azure Workload Identity lets pods in Azure Kubernetes Service (AKS) authenticate to Azure Blob Storage using a Kubernetes service account federated with `Microsoft Entra ID`. + +Before using workload identity authentication, assign an appropriate Azure RBAC role (Storage Blob Data Reader, Contributor, or Owner) to the federated credential at the storage account or container scope.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pipeline/outputs/azure_blob.md` around lines 246 - 249, Update the "Configuration for workload identity" section to explicitly document that Azure RBAC role assignments are required: state that the federated credential (Kubernetes service account's federated identity) must be assigned a Storage Blob Data role (e.g., Storage Blob Data Reader or Storage Blob Data Contributor) at the storage account or container scope before it can access blobs, and show where to assign this role via the Portal/CLI/ARM; reference the "Configuration for workload identity" heading so readers can find the guidance and include a short note about choosing the minimum scope and role for least privilege.
128-131:⚠️ Potential issue | 🟡 MinorAdd required RBAC role configuration guidance.
A past review comment correctly noted that identity-based authentication requires Azure RBAC role assignment. Users must assign a Storage Blob Data role (Reader, Contributor, or Owner) to the managed identity at the storage account or container scope before authentication will succeed. Without this step, users will encounter access denied errors despite correct authentication configuration.
📋 Suggested addition
### Configuration for managed identity Azure Managed Identity lets your application authenticate to Azure Blob Storage without managing credentials. This works on Azure VMs, Azure Container Instances, Azure App Service, and other Azure compute services with managed identity support. + +Before using managed identity authentication, assign an appropriate Azure RBAC role to the identity: +- **Storage Blob Data Reader** for read and list operations +- **Storage Blob Data Contributor** for read, write, and delete operations +- **Storage Blob Data Owner** for full data-plane access + +Assign the role at the storage account scope (for all containers) or container scope (for a specific container) using the Azure Portal, CLI, or ARM templates.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pipeline/outputs/azure_blob.md` around lines 128 - 131, Update the "Configuration for managed identity" section to explicitly state that Azure RBAC role assignment is required for identity-based access: instruct users to assign a Storage Blob Data role (Reader, Contributor, or Owner) to the managed identity at the storage account or container scope before attempting authentication, note that missing this step causes access denied errors, and suggest best-practice scope guidance (use container-level for least privilege, storage account for broader access) and mention where users typically perform the assignment (Portal/CLI/ARM templates) so they can locate the setting.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pipeline/outputs/azure_blob.md`:
- Around line 163-183: The example fluent-bit.conf uses lowercase plugin keys in
the [SERVICE] and [INPUT] blocks (e.g., flush, log_level, name, dummy, samples,
tag) which is inconsistent with the Title_Case convention used elsewhere; update
those keys to Title_Case (e.g., Flush, Log_Level, Name, Dummy, Samples, Tag) and
likewise ensure plugin-specific keys in the [OUTPUT] azure_blob block follow
Title_Case (e.g., Account_Name, Auth_Type, Client_Id, Container_Name,
Auto_Create_Container, TLS) so the example matches the documented convention and
other examples.
---
Duplicate comments:
In `@pipeline/outputs/azure_blob.md`:
- Around line 221-241: Update the fluent-bit.conf example in the [OUTPUT]
azure_blob block to use Title_Case for plugin-specific keys (e.g., change
account_name, auth_type, client_id, container_name, auto_create_container, tls,
match, name to Account_Name, Auth_Type, Client_Id, Container_Name,
Auto_Create_Container, TLS, Match, Name) so the example matches the Title_Case
style used in the system-assigned managed identity sample; edit the azure_blob
[OUTPUT] stanza (keys: name, match, account_name, auth_type, client_id,
container_name, auto_create_container, tls) accordingly.
- Around line 280-301: The fluent-bit example uses snake_case plugin keys;
change plugin-specific keys in the [OUTPUT] azure_blob block (e.g.,
account_name, auth_type, client_id, tenant_id, container_name,
auto_create_container, tls, match, name) to Title_Case as in other
managed-identity examples (e.g., Account_Name, Auth_Type, Client_ID, Tenant_ID,
Container_Name, Auto_Create_Container, TLS, Match, Name) so the example matches
the project's fluent-bit style; update only the keys' casing and keep their
values unchanged.
- Around line 246-249: Update the "Configuration for workload identity" section
to explicitly document that Azure RBAC role assignments are required: state that
the federated credential (Kubernetes service account's federated identity) must
be assigned a Storage Blob Data role (e.g., Storage Blob Data Reader or Storage
Blob Data Contributor) at the storage account or container scope before it can
access blobs, and show where to assign this role via the Portal/CLI/ARM;
reference the "Configuration for workload identity" heading so readers can find
the guidance and include a short note about choosing the minimum scope and role
for least privilege.
- Around line 128-131: Update the "Configuration for managed identity" section
to explicitly state that Azure RBAC role assignment is required for
identity-based access: instruct users to assign a Storage Blob Data role
(Reader, Contributor, or Owner) to the managed identity at the storage account
or container scope before attempting authentication, note that missing this step
causes access denied errors, and suggest best-practice scope guidance (use
container-level for least privilege, storage account for broader access) and
mention where users typically perform the assignment (Portal/CLI/ARM templates)
so they can locate the setting.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 222c7673-9090-468d-9e35-617135099139
📒 Files selected for processing (1)
pipeline/outputs/azure_blob.md
Signed-off-by: Hannes Schulz <Hannes.Schulz@microsoft.com>
Document new
auth_typevalues (managed_identity,workload_identity) and related configuration parameters (client_id,tenant_id,workload_identity_token_file) for the Azure Blob output plugin, with configuration examples for system-assigned MI, user-assigned MI, and workload identity.Companion to fluent/fluent-bit#10777.
Summary by CodeRabbit