From ae904d9378e3eba126d84117251b7e0562880ee9 Mon Sep 17 00:00:00 2001 From: Jorge Turrado Date: Fri, 13 Oct 2023 23:22:14 +0200 Subject: [PATCH 1/3] chore: Add an explanation about Azure Workliad Identity federations during overrides Signed-off-by: Jorge Turrado --- .../azure-ad-workload-identity.md | 29 +++++++++++++++++++ .../azure-ad-workload-identity.md | 29 +++++++++++++++++++ .../azure-ad-workload-identity.md | 29 +++++++++++++++++++ .../azure-ad-workload-identity.md | 26 +++++++++++++++++ .../azure-ad-workload-identity.md | 29 +++++++++++++++++++ .../azure-ad-workload-identity.md | 29 +++++++++++++++++++ 6 files changed, 171 insertions(+) diff --git a/content/docs/2.10/authentication-providers/azure-ad-workload-identity.md b/content/docs/2.10/authentication-providers/azure-ad-workload-identity.md index 136f5531c..afdee7f00 100644 --- a/content/docs/2.10/authentication-providers/azure-ad-workload-identity.md +++ b/content/docs/2.10/authentication-providers/azure-ad-workload-identity.md @@ -23,3 +23,32 @@ following flags - 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. + +## Considerations about Federations and Overrides + +The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure Identity to ensure proper functionality. Let's clarify this with two examples: + +### Case 1 + +Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: + +- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). +- Workload A's identity with access to Service Bus A. +- Workload B's identity with access to Service Bus B. +- Workload C's identity with access to Service Bus C. + +In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. + +### Case 2 + +To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: + +- KEDA's identity without access to any Service Bus. +- Workload A's identity with access to Service Bus A. +- Workload B's identity with access to Service Bus B. +- Workload C's identity with access to Service Bus C. + +In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: + +- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). +- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). diff --git a/content/docs/2.11/authentication-providers/azure-ad-workload-identity.md b/content/docs/2.11/authentication-providers/azure-ad-workload-identity.md index 136f5531c..afdee7f00 100644 --- a/content/docs/2.11/authentication-providers/azure-ad-workload-identity.md +++ b/content/docs/2.11/authentication-providers/azure-ad-workload-identity.md @@ -23,3 +23,32 @@ following flags - 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. + +## Considerations about Federations and Overrides + +The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure Identity to ensure proper functionality. Let's clarify this with two examples: + +### Case 1 + +Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: + +- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). +- Workload A's identity with access to Service Bus A. +- Workload B's identity with access to Service Bus B. +- Workload C's identity with access to Service Bus C. + +In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. + +### Case 2 + +To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: + +- KEDA's identity without access to any Service Bus. +- Workload A's identity with access to Service Bus A. +- Workload B's identity with access to Service Bus B. +- Workload C's identity with access to Service Bus C. + +In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: + +- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). +- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). diff --git a/content/docs/2.12/authentication-providers/azure-ad-workload-identity.md b/content/docs/2.12/authentication-providers/azure-ad-workload-identity.md index 136f5531c..afdee7f00 100644 --- a/content/docs/2.12/authentication-providers/azure-ad-workload-identity.md +++ b/content/docs/2.12/authentication-providers/azure-ad-workload-identity.md @@ -23,3 +23,32 @@ following flags - 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. + +## Considerations about Federations and Overrides + +The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure Identity to ensure proper functionality. Let's clarify this with two examples: + +### Case 1 + +Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: + +- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). +- Workload A's identity with access to Service Bus A. +- Workload B's identity with access to Service Bus B. +- Workload C's identity with access to Service Bus C. + +In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. + +### Case 2 + +To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: + +- KEDA's identity without access to any Service Bus. +- Workload A's identity with access to Service Bus A. +- Workload B's identity with access to Service Bus B. +- Workload C's identity with access to Service Bus C. + +In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: + +- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). +- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). diff --git a/content/docs/2.13/authentication-providers/azure-ad-workload-identity.md b/content/docs/2.13/authentication-providers/azure-ad-workload-identity.md index 136f5531c..dd2352947 100644 --- a/content/docs/2.13/authentication-providers/azure-ad-workload-identity.md +++ b/content/docs/2.13/authentication-providers/azure-ad-workload-identity.md @@ -23,3 +23,29 @@ following flags - 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. + +## Considerations about Federations and Overrides +The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure Identity to ensure proper functionality. Let's clarify this with two examples: + +### Case 1 +Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: + +- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). +- Workload A's identity with access to Service Bus A. +- Workload B's identity with access to Service Bus B. +- Workload C's identity with access to Service Bus C. + +In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. + +### Case 2 +To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: + +- KEDA's identity without access to any Service Bus. +- Workload A's identity with access to Service Bus A. +- Workload B's identity with access to Service Bus B. +- Workload C's identity with access to Service Bus C. + +In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: + +- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). +- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). diff --git a/content/docs/2.8/authentication-providers/azure-ad-workload-identity.md b/content/docs/2.8/authentication-providers/azure-ad-workload-identity.md index 136f5531c..afdee7f00 100644 --- a/content/docs/2.8/authentication-providers/azure-ad-workload-identity.md +++ b/content/docs/2.8/authentication-providers/azure-ad-workload-identity.md @@ -23,3 +23,32 @@ following flags - 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. + +## Considerations about Federations and Overrides + +The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure Identity to ensure proper functionality. Let's clarify this with two examples: + +### Case 1 + +Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: + +- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). +- Workload A's identity with access to Service Bus A. +- Workload B's identity with access to Service Bus B. +- Workload C's identity with access to Service Bus C. + +In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. + +### Case 2 + +To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: + +- KEDA's identity without access to any Service Bus. +- Workload A's identity with access to Service Bus A. +- Workload B's identity with access to Service Bus B. +- Workload C's identity with access to Service Bus C. + +In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: + +- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). +- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). diff --git a/content/docs/2.9/authentication-providers/azure-ad-workload-identity.md b/content/docs/2.9/authentication-providers/azure-ad-workload-identity.md index 136f5531c..afdee7f00 100644 --- a/content/docs/2.9/authentication-providers/azure-ad-workload-identity.md +++ b/content/docs/2.9/authentication-providers/azure-ad-workload-identity.md @@ -23,3 +23,32 @@ following flags - 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. + +## Considerations about Federations and Overrides + +The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure Identity to ensure proper functionality. Let's clarify this with two examples: + +### Case 1 + +Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: + +- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). +- Workload A's identity with access to Service Bus A. +- Workload B's identity with access to Service Bus B. +- Workload C's identity with access to Service Bus C. + +In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. + +### Case 2 + +To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: + +- KEDA's identity without access to any Service Bus. +- Workload A's identity with access to Service Bus A. +- Workload B's identity with access to Service Bus B. +- Workload C's identity with access to Service Bus C. + +In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: + +- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). +- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). From fb76b77d8da620686219d369803e992ee24a2341 Mon Sep 17 00:00:00 2001 From: Jorge Turrado Date: Sat, 14 Oct 2023 00:43:23 +0200 Subject: [PATCH 2/3] chore: Add an explanation about Azure Workliad Identity federations during overrides Signed-off-by: Jorge Turrado --- .../authentication-providers/azure-ad-workload-identity.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/content/docs/2.13/authentication-providers/azure-ad-workload-identity.md b/content/docs/2.13/authentication-providers/azure-ad-workload-identity.md index dd2352947..afdee7f00 100644 --- a/content/docs/2.13/authentication-providers/azure-ad-workload-identity.md +++ b/content/docs/2.13/authentication-providers/azure-ad-workload-identity.md @@ -25,9 +25,11 @@ following flags - You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ## Considerations about Federations and Overrides + The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure Identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 + Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). @@ -38,6 +40,7 @@ Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBu In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 + To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. From 67e4640d05ba52425106c528fa381c60336f4557 Mon Sep 17 00:00:00 2001 From: Jorge Turrado Date: Thu, 11 Jan 2024 08:51:32 +0100 Subject: [PATCH 3/3] apply feedback Signed-off-by: Jorge Turrado --- .../authentication-providers/azure-ad-workload-identity.md | 4 +++- .../authentication-providers/azure-ad-workload-identity.md | 4 +++- .../authentication-providers/azure-ad-workload-identity.md | 4 +++- .../authentication-providers/azure-ad-workload-identity.md | 4 +++- .../authentication-providers/azure-ad-workload-identity.md | 4 +++- .../authentication-providers/azure-ad-workload-identity.md | 4 +++- 6 files changed, 18 insertions(+), 6 deletions(-) diff --git a/content/docs/2.10/authentication-providers/azure-ad-workload-identity.md b/content/docs/2.10/authentication-providers/azure-ad-workload-identity.md index afdee7f00..24e465d1f 100644 --- a/content/docs/2.10/authentication-providers/azure-ad-workload-identity.md +++ b/content/docs/2.10/authentication-providers/azure-ad-workload-identity.md @@ -26,7 +26,9 @@ You can override the identity that was assigned to KEDA during installation, by ## Considerations about Federations and Overrides -The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure Identity to ensure proper functionality. Let's clarify this with two examples: +The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. + +Let's clarify this with two examples: ### Case 1 diff --git a/content/docs/2.11/authentication-providers/azure-ad-workload-identity.md b/content/docs/2.11/authentication-providers/azure-ad-workload-identity.md index afdee7f00..24e465d1f 100644 --- a/content/docs/2.11/authentication-providers/azure-ad-workload-identity.md +++ b/content/docs/2.11/authentication-providers/azure-ad-workload-identity.md @@ -26,7 +26,9 @@ You can override the identity that was assigned to KEDA during installation, by ## Considerations about Federations and Overrides -The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure Identity to ensure proper functionality. Let's clarify this with two examples: +The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. + +Let's clarify this with two examples: ### Case 1 diff --git a/content/docs/2.12/authentication-providers/azure-ad-workload-identity.md b/content/docs/2.12/authentication-providers/azure-ad-workload-identity.md index afdee7f00..24e465d1f 100644 --- a/content/docs/2.12/authentication-providers/azure-ad-workload-identity.md +++ b/content/docs/2.12/authentication-providers/azure-ad-workload-identity.md @@ -26,7 +26,9 @@ You can override the identity that was assigned to KEDA during installation, by ## Considerations about Federations and Overrides -The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure Identity to ensure proper functionality. Let's clarify this with two examples: +The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. + +Let's clarify this with two examples: ### Case 1 diff --git a/content/docs/2.13/authentication-providers/azure-ad-workload-identity.md b/content/docs/2.13/authentication-providers/azure-ad-workload-identity.md index afdee7f00..24e465d1f 100644 --- a/content/docs/2.13/authentication-providers/azure-ad-workload-identity.md +++ b/content/docs/2.13/authentication-providers/azure-ad-workload-identity.md @@ -26,7 +26,9 @@ You can override the identity that was assigned to KEDA during installation, by ## Considerations about Federations and Overrides -The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure Identity to ensure proper functionality. Let's clarify this with two examples: +The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. + +Let's clarify this with two examples: ### Case 1 diff --git a/content/docs/2.8/authentication-providers/azure-ad-workload-identity.md b/content/docs/2.8/authentication-providers/azure-ad-workload-identity.md index afdee7f00..24e465d1f 100644 --- a/content/docs/2.8/authentication-providers/azure-ad-workload-identity.md +++ b/content/docs/2.8/authentication-providers/azure-ad-workload-identity.md @@ -26,7 +26,9 @@ You can override the identity that was assigned to KEDA during installation, by ## Considerations about Federations and Overrides -The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure Identity to ensure proper functionality. Let's clarify this with two examples: +The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. + +Let's clarify this with two examples: ### Case 1 diff --git a/content/docs/2.9/authentication-providers/azure-ad-workload-identity.md b/content/docs/2.9/authentication-providers/azure-ad-workload-identity.md index afdee7f00..24e465d1f 100644 --- a/content/docs/2.9/authentication-providers/azure-ad-workload-identity.md +++ b/content/docs/2.9/authentication-providers/azure-ad-workload-identity.md @@ -26,7 +26,9 @@ You can override the identity that was assigned to KEDA during installation, by ## Considerations about Federations and Overrides -The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure Identity to ensure proper functionality. Let's clarify this with two examples: +The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. + +Let's clarify this with two examples: ### Case 1