From d8e2ac049358690efaf4ae6fa8e6c364003067df Mon Sep 17 00:00:00 2001 From: KsaweryZietara <91937141+KsaweryZietara@users.noreply.github.com> Date: Fri, 17 Jan 2025 10:28:02 +0100 Subject: [PATCH] Correct Labels to lowerCamelCase in HAP Documentation (#1647) --- .../03-10-hyperscaler-account-pool.md | 28 +++++++++---------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/contributor/03-10-hyperscaler-account-pool.md b/docs/contributor/03-10-hyperscaler-account-pool.md index 4b408946b6..bc9ed01b32 100644 --- a/docs/contributor/03-10-hyperscaler-account-pool.md +++ b/docs/contributor/03-10-hyperscaler-account-pool.md @@ -2,7 +2,7 @@ To provision clusters through Gardener using Runtime Provisioner, Kyma Environment Broker (KEB) requires a hyperscaler (GCP, Azure, AWS, etc.) account/subscription. Managing the available hyperscaler accounts is not in the scope of KEB. Instead, the available accounts are handled by Hyperscaler Account Pool (HAP). -HAP stores credentials for the hyperscaler accounts that have been set up in advance in Kubernetes Secrets. The credentials are stored separately for each provider and tenant. The content of the credentials Secrets may vary for different use cases. The Secrets are labeled with the **hyperscaler-type** and **tenant-name** labels to manage pools of credentials for use by the provisioning process. This way, the in-use credentials and unassigned credentials available for use are tracked. Only the **hyperscaler-type** label is added during Secret creation, and the **tenant-name** label is added when the account respective for a given Secret is claimed. The content of the Secrets is opaque to HAP. +HAP stores credentials for the hyperscaler accounts that have been set up in advance in Kubernetes Secrets. The credentials are stored separately for each provider and tenant. The content of the credentials Secrets may vary for different use cases. The Secrets are labeled with the **hyperscalerType** and **tenantName** labels to manage pools of credentials for use by the provisioning process. This way, the in-use credentials and unassigned credentials available for use are tracked. Only the **hyperscalerType** label is added during Secret creation, and the **tenantName** label is added when the account respective for a given Secret is claimed. The content of the Secrets is opaque to HAP. The Secrets are stored in a Gardener seed cluster pointed to by HAP. They are available within a given Gardener project specified in the KEB and Runtime Provisioner configuration. This configuration uses a `kubeconfig` that gives KEB and Runtime Provisioner access to a specific Gardener seed cluster, which, in turn, enables access to those Secrets. @@ -10,8 +10,8 @@ This diagram shows the HAP workflow: ![hap-workflow](../assets/hap-flow.drawio.svg) -Before a new cluster is provisioned, KEB queries for a Secret based on the **tenant-name** and **hyperscaler-type** labels. -If a Secret is found, KEB uses the credentials stored in this Secret. If a matching Secret is not found, KEB queries again for an unassigned Secret for a given hyperscaler and adds the **tenant-name** label to claim the account and use the credentials for provisioning. +Before a new cluster is provisioned, KEB queries for a Secret based on the **tenantName** and **hyperscalerType** labels. +If a Secret is found, KEB uses the credentials stored in this Secret. If a matching Secret is not found, KEB queries again for an unassigned Secret for a given hyperscaler and adds the **tenantName** label to claim the account and use the credentials for provisioning. One tenant can use only one account per given hyperscaler type. @@ -23,9 +23,9 @@ kind: Secret metadata: name: {SECRET_NAME} labels: - # tenant-name is omitted for new, not yet claimed account credentials - tenant-name: {TENANT_NAME} - hyperscaler-type: {HYPERSCALER_TYPE} + # tenantName is omitted for new, not yet claimed account credentials + tenantName: {TENANT_NAME} + hyperscalerType: {HYPERSCALER_TYPE} ``` ## Shared Credentials @@ -43,7 +43,7 @@ kind: Secret metadata: name: {SECRET_NAME} labels: - hyperscaler-type: {HYPERSCALER_TYPE} + hyperscalerType: {HYPERSCALER_TYPE} shared: "true" ``` @@ -61,16 +61,16 @@ kind: Secret metadata: name: {SECRET_NAME} labels: - # tenant-name is omitted for new, not yet claimed account credentials - tenant-name: {TENANT_NAME} - hyperscaler-type: {HYPERSCALER_TYPE} + # tenantName is omitted for new, not yet claimed account credentials + tenantName: {TENANT_NAME} + hyperscalerType: {HYPERSCALER_TYPE} euAccess: "true" ``` ## Assured Workloads SAP BTP, Kyma runtime supports the BTP cf-sa30 GCP subaccount region. This region uses the Assured Workloads Kingdom of Saudi Arabia (KSA) control package. Kyma Control Plane manages cf-sa30 Kyma runtimes in a separate -Google Cloud hyperscaler account pool. The Secret contains the label **hyperscaler-type** set to `gcp_cf-sa30`. The following is an example of a Secret that uses the Assured Workloads KSA control package: +Google Cloud hyperscaler account pool. The Secret contains the label **hyperscalerType** set to `gcp_cf-sa30`. The following is an example of a Secret that uses the Assured Workloads KSA control package: ```yaml apiVersion: v1 @@ -78,7 +78,7 @@ kind: Secret metadata: name: {SECRET_NAME} labels: - # tenant-name is omitted for new, not yet claimed account credentials - tenant-name: {TENANT_NAME} - hyperscaler-type: "gcp_cf-sa30" + # tenantName is omitted for new, not yet claimed account credentials + tenantName: {TENANT_NAME} + hyperscalerType: "gcp_cf-sa30" ```