From b0bec168f28f581d5bc05bbece7550b53a70ebeb Mon Sep 17 00:00:00 2001 From: Aniruddha Basak Date: Wed, 19 Aug 2026 12:38:17 +0200 Subject: [PATCH 1/9] add workload identity doc --- docs/usage/usage.md | 205 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 205 insertions(+) create mode 100644 docs/usage/usage.md diff --git a/docs/usage/usage.md b/docs/usage/usage.md new file mode 100644 index 00000000..27bc26b2 --- /dev/null +++ b/docs/usage/usage.md @@ -0,0 +1,205 @@ +# Using the STACKIT provider extension with Gardener as end-user + +## STACKIT Workload Identity + +The STACKIT provider extension deploys and configures the +[`stackit-pod-identity-webhook`](https://github.com/stackitcloud/stackit-pod-identity-webhook) +in the Shoot control plane. This enables workloads running in SKE clusters to use +STACKIT Workload Identity without storing long-lived STACKIT credentials in Pods. + +The extension is responsible for making the token-injection mechanism available +to the Shoot cluster. The trust relationship between the cluster and a STACKIT +Service Account is configured separately in the STACKIT Identity Provider (IdP). + + +STACKIT Workload Identity uses OIDC federation to exchange a Kubernetes +ServiceAccount token for a short-lived STACKIT access token. + +The flow is: + +1. The Kubernetes API server issues a projected, audience-bound ServiceAccount token. +2. The `stackit-pod-identity-webhook` injects the token and the required STACKIT SDK + environment variables into Pods using an annotated Kubernetes `ServiceAccount`. +3. The STACKIT SDK exchanges the projected token with the STACKIT IdP. +4. The IdP validates the token against the Shoot's OIDC issuer and configured + assertions. +5. The workload receives a short-lived STACKIT access token and uses it to call + STACKIT APIs. + +This removes the need for static service account keys in workloads. + +## What the STACKIT provider extension provides + +The provider extension: + +- deploys the `stackit-pod-identity-webhook` into the Shoot control plane; +- configures the webhook so it can mutate Pods in the Shoot cluster; and +- provides the webhook with the TLS configuration required for communication + with the Kubernetes API server. + +No manual installation of the webhook is required for SKE clusters. + +The extension does **not** create the STACKIT Service Account federation or define +which Kubernetes identities may assume it. This trust relationship is configured +in the STACKIT IdP. + +## Prerequisites + +Before configuring a workload, you need: + +- a STACKIT project; +- a STACKIT Service Account with the permissions required by the workload; and +- an SKE cluster with Workload Identity support enabled. + +## Step 1: Establish a trust relationship + +The STACKIT IdP must trust the OIDC issuer of the Shoot cluster. + +For a cluster created through SKE, retrieve the `serviceAccountIssuer` from the +cluster status. For example: + +```bash +stackit ske cluster describe -p -o json \ + | jq -r '.status.serviceAccountIssuer' +``` + +When a new cluster is created, the `serviceAccountIssuer` can be populated +asynchronously. Fetch the cluster status again after the initial provisioning +request if the field is not present. + +Create a **Federated Identity Provider** for the STACKIT Service Account in the +[STACKIT Portal](https://portal.stackit.cloud/), using the returned issuer URL. + +At minimum, restrict the federation with the Kubernetes `sub` claim: + +```text +system:serviceaccount:: +``` + +For example: + +```text +system:serviceaccount:default:app +``` + +You should also configure the audience assertion expected by the workload. The +default STACKIT Workload Identity audience is: + +```text +sts.accounts.stackit.cloud +``` + +See the STACKIT documentation for +[creating and managing federated identity providers](https://docs.stackit.cloud/platform/access-and-identity/service-accounts/how-tos/manage-service-account-federations/). + +## Step 2: Configure the workload + +Annotate the Kubernetes `ServiceAccount` with the STACKIT Service Account email. +Pods using this `ServiceAccount` are then mutated automatically by the webhook. + +A minimal example: + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + name: app + namespace: default + annotations: + workload-identity.stackit.cloud/service-account-email: "my-service-account@sa.stackit.cloud" +--- +apiVersion: v1 +kind: Pod +metadata: + name: app + namespace: default +spec: + serviceAccountName: app + automountServiceAccountToken: false + containers: + - name: app + image: +``` + +The `workload-identity.stackit.cloud/service-account-email` annotation is the +required setting for enabling STACKIT Workload Identity for the `ServiceAccount`. + +When the Pod is created, the webhook injects: + +- a projected ServiceAccount token; +- `STACKIT_FEDERATED_TOKEN_FILE`; +- `STACKIT_SERVICE_ACCOUNT_EMAIL`; and +- optional STACKIT IdP configuration variables when configured. + +The token is mounted at: + +```text +/var/run/secrets/stackit.cloud/serviceaccount/token +``` + +Applications using the STACKIT SDK can use the injected configuration +automatically. + +## Configuration reference + +The following `ServiceAccount` annotations are supported by the +`stackit-pod-identity-webhook`: + +| Annotation | Default | Description | +| --- | --- | --- | +| `workload-identity.stackit.cloud/service-account-email` | None | STACKIT Service Account email to assume. **Required.** | +| `workload-identity.stackit.cloud/audience` | `sts.accounts.stackit.cloud` | Audience of the projected ServiceAccount token. | +| `workload-identity.stackit.cloud/service-account-token-expiration-seconds` | `600` | Lifetime of the projected ServiceAccount token. | +| `workload-identity.stackit.cloud/idp-token-expiration-seconds` | SDK default (`3600`) | Requested lifetime of the token returned by the IdP. | +| `workload-identity.stackit.cloud/idp-token-endpoint` | `https://accounts.stackit.cloud/oauth/v2/token` | Token exchange endpoint. Useful for non-default IdP environments. | + +Pods or namespaces can opt out of mutation with: + +```yaml +metadata: + labels: + workload-identity.stackit.cloud/skip-pod-identity-webhook: "true" +``` + +## Security considerations + +Use a dedicated Kubernetes `ServiceAccount` for each external identity where +practical, and keep the federation assertion as narrow as possible. + +For a `ServiceAccount` used only for Workload Identity, set: + +```yaml +automountServiceAccountToken: false +``` + +This prevents the normal ServiceAccount token from being mounted for generic +Kubernetes API access while the webhook still provides the projected token used +for federation. + +Pods running on SKE worker VMs may also be able to reach the VM metadata service +and obtain infrastructure credentials. If workloads must not access VM +credentials, restrict egress to the metadata IP (`169.254.169.254`) with a +Kubernetes `NetworkPolicy`. + +## Token and signing-key rotation + +Projected ServiceAccount tokens are short-lived and automatically refreshed. +The default projected-token lifetime is 10 minutes. + +SKE cluster ServiceAccount signing keys can be rotated through the normal +Gardener/SKE credential rotation process. During rotation, the STACKIT IdP caches +the cluster JWKS for up to one hour, so tokens signed with a previous key may +remain accepted for a limited time after rotation. Keeping the projected token +TTL short reduces this exposure. + +See the [SKE credential rotation documentation](https://docs.stackit.cloud/products/runtime/kubernetes-engine/how-tos/rotate-ske-credentials/) +and the [Gardener ServiceAccount signing-key documentation](https://gardener.cloud/docs/gardener/shoot-operations/shoot_credentials_rotation/#serviceaccount-token-signing-key) +for the operational rotation procedure. + +## References + +- [STACKIT Workload Identity](https://docs.stackit.cloud/products/runtime/kubernetes-engine/how-tos/workload-identity/) +- [STACKIT Service Account Federation](https://docs.stackit.cloud/platform/access-and-identity/service-accounts/how-tos/manage-service-account-federations/) +- [`stackit-pod-identity-webhook`](https://github.com/stackitcloud/stackit-pod-identity-webhook) +- [Gardener Managed Service Account Issuer](https://gardener.cloud/docs/gardener/security/shoot_serviceaccounts/#managed-service-account-issuer) +- [Kubernetes ServiceAccount token projection](https://kubernetes.io/docs/concepts/storage/projected-volumes/#serviceaccounttoken) From 7a21140398cf04d37acefed5ef229e807e319b03 Mon Sep 17 00:00:00 2001 From: Aniruddha Basak Date: Wed, 19 Aug 2026 15:23:05 +0200 Subject: [PATCH 2/9] update as per jans review --- docs/usage/usage.md | 187 ++++++-------------------------------------- 1 file changed, 25 insertions(+), 162 deletions(-) diff --git a/docs/usage/usage.md b/docs/usage/usage.md index 27bc26b2..ae32aa92 100644 --- a/docs/usage/usage.md +++ b/docs/usage/usage.md @@ -1,103 +1,37 @@ # Using the STACKIT provider extension with Gardener as end-user -## STACKIT Workload Identity +## STACKIT Workload Identity with Gardener -The STACKIT provider extension deploys and configures the -[`stackit-pod-identity-webhook`](https://github.com/stackitcloud/stackit-pod-identity-webhook) -in the Shoot control plane. This enables workloads running in SKE clusters to use -STACKIT Workload Identity without storing long-lived STACKIT credentials in Pods. +This extension automatically deploys and configures the `stackit-pod-identity-webhook` in your SKE cluster's control plane, enabling workloads to use STACKIT Workload Identity. -The extension is responsible for making the token-injection mechanism available -to the Shoot cluster. The trust relationship between the cluster and a STACKIT -Service Account is configured separately in the STACKIT Identity Provider (IdP). +### What this extension provides +- Automatic deployment of the `stackit-pod-identity-webhook` in the Shoot control plane +- Webhook configuration to inject STACKIT authentication into Pods +- TLS setup for webhook communication with the Kubernetes API server -STACKIT Workload Identity uses OIDC federation to exchange a Kubernetes -ServiceAccount token for a short-lived STACKIT access token. +No manual webhook installation is required — the extension handles this for you. -The flow is: +### Quick start -1. The Kubernetes API server issues a projected, audience-bound ServiceAccount token. -2. The `stackit-pod-identity-webhook` injects the token and the required STACKIT SDK - environment variables into Pods using an annotated Kubernetes `ServiceAccount`. -3. The STACKIT SDK exchanges the projected token with the STACKIT IdP. -4. The IdP validates the token against the Shoot's OIDC issuer and configured - assertions. -5. The workload receives a short-lived STACKIT access token and uses it to call - STACKIT APIs. +**Prerequisites:** -This removes the need for static service account keys in workloads. +- An SKE cluster with Workload Identity support enabled +- A STACKIT Service Account with appropriate permissions +- A federated identity configured in the STACKIT IdP -## What the STACKIT provider extension provides +#### Create a federated identity in STACKIT -The provider extension: - -- deploys the `stackit-pod-identity-webhook` into the Shoot control plane; -- configures the webhook so it can mutate Pods in the Shoot cluster; and -- provides the webhook with the TLS configuration required for communication - with the Kubernetes API server. - -No manual installation of the webhook is required for SKE clusters. - -The extension does **not** create the STACKIT Service Account federation or define -which Kubernetes identities may assume it. This trust relationship is configured -in the STACKIT IdP. - -## Prerequisites - -Before configuring a workload, you need: - -- a STACKIT project; -- a STACKIT Service Account with the permissions required by the workload; and -- an SKE cluster with Workload Identity support enabled. - -## Step 1: Establish a trust relationship - -The STACKIT IdP must trust the OIDC issuer of the Shoot cluster. - -For a cluster created through SKE, retrieve the `serviceAccountIssuer` from the -cluster status. For example: +Retrieve your cluster's OIDC issuer: ```bash stackit ske cluster describe -p -o json \ | jq -r '.status.serviceAccountIssuer' ``` -When a new cluster is created, the `serviceAccountIssuer` can be populated -asynchronously. Fetch the cluster status again after the initial provisioning -request if the field is not present. - -Create a **Federated Identity Provider** for the STACKIT Service Account in the -[STACKIT Portal](https://portal.stackit.cloud/), using the returned issuer URL. - -At minimum, restrict the federation with the Kubernetes `sub` claim: - -```text -system:serviceaccount:: -``` - -For example: - -```text -system:serviceaccount:default:app -``` - -You should also configure the audience assertion expected by the workload. The -default STACKIT Workload Identity audience is: - -```text -sts.accounts.stackit.cloud -``` - -See the STACKIT documentation for -[creating and managing federated identity providers](https://docs.stackit.cloud/platform/access-and-identity/service-accounts/how-tos/manage-service-account-federations/). - -## Step 2: Configure the workload +Create a Federated Identity Provider in the STACKIT Portal using this issuer URL. Restrict the federation with the Kubernetes `sub` claim: `system:serviceaccount::` -Annotate the Kubernetes `ServiceAccount` with the STACKIT Service Account email. -Pods using this `ServiceAccount` are then mutated automatically by the webhook. - -A minimal example: +#### Annotate your Kubernetes `ServiceAccount` ```yaml apiVersion: v1 @@ -107,98 +41,27 @@ metadata: namespace: default annotations: workload-identity.stackit.cloud/service-account-email: "my-service-account@sa.stackit.cloud" ---- -apiVersion: v1 -kind: Pod -metadata: - name: app - namespace: default -spec: - serviceAccountName: app - automountServiceAccountToken: false - containers: - - name: app - image: -``` - -The `workload-identity.stackit.cloud/service-account-email` annotation is the -required setting for enabling STACKIT Workload Identity for the `ServiceAccount`. - -When the Pod is created, the webhook injects: - -- a projected ServiceAccount token; -- `STACKIT_FEDERATED_TOKEN_FILE`; -- `STACKIT_SERVICE_ACCOUNT_EMAIL`; and -- optional STACKIT IdP configuration variables when configured. - -The token is mounted at: - -```text -/var/run/secrets/stackit.cloud/serviceaccount/token ``` -Applications using the STACKIT SDK can use the injected configuration -automatically. - -## Configuration reference +Pods using this `ServiceAccount` will automatically have STACKIT authentication injected. -The following `ServiceAccount` annotations are supported by the -`stackit-pod-identity-webhook`: +### Supported annotations | Annotation | Default | Description | | --- | --- | --- | | `workload-identity.stackit.cloud/service-account-email` | None | STACKIT Service Account email to assume. **Required.** | -| `workload-identity.stackit.cloud/audience` | `sts.accounts.stackit.cloud` | Audience of the projected ServiceAccount token. | -| `workload-identity.stackit.cloud/service-account-token-expiration-seconds` | `600` | Lifetime of the projected ServiceAccount token. | -| `workload-identity.stackit.cloud/idp-token-expiration-seconds` | SDK default (`3600`) | Requested lifetime of the token returned by the IdP. | -| `workload-identity.stackit.cloud/idp-token-endpoint` | `https://accounts.stackit.cloud/oauth/v2/token` | Token exchange endpoint. Useful for non-default IdP environments. | - -Pods or namespaces can opt out of mutation with: - -```yaml -metadata: - labels: - workload-identity.stackit.cloud/skip-pod-identity-webhook: "true" -``` - -## Security considerations - -Use a dedicated Kubernetes `ServiceAccount` for each external identity where -practical, and keep the federation assertion as narrow as possible. - -For a `ServiceAccount` used only for Workload Identity, set: - -```yaml -automountServiceAccountToken: false -``` - -This prevents the normal ServiceAccount token from being mounted for generic -Kubernetes API access while the webhook still provides the projected token used -for federation. - -Pods running on SKE worker VMs may also be able to reach the VM metadata service -and obtain infrastructure credentials. If workloads must not access VM -credentials, restrict egress to the metadata IP (`169.254.169.254`) with a -Kubernetes `NetworkPolicy`. - -## Token and signing-key rotation +| `workload-identity.stackit.cloud/audience` | `sts.accounts.stackit.cloud` | Audience for the token. | +| `workload-identity.stackit.cloud/service-account-token-expiration-seconds` | `600` | Token lifetime in seconds. | +| `workload-identity.stackit.cloud/idp-token-endpoint` | `https://accounts.stackit.cloud/oauth/v2/token` | Token exchange endpoint. | -Projected ServiceAccount tokens are short-lived and automatically refreshed. -The default projected-token lifetime is 10 minutes. +Opt out of mutation with: `workload-identity.stackit.cloud/skip-pod-identity-webhook: "true"` label on Pod or Namespace. -SKE cluster ServiceAccount signing keys can be rotated through the normal -Gardener/SKE credential rotation process. During rotation, the STACKIT IdP caches -the cluster JWKS for up to one hour, so tokens signed with a previous key may -remain accepted for a limited time after rotation. Keeping the projected token -TTL short reduces this exposure. +### Learn more -See the [SKE credential rotation documentation](https://docs.stackit.cloud/products/runtime/kubernetes-engine/how-tos/rotate-ske-credentials/) -and the [Gardener ServiceAccount signing-key documentation](https://gardener.cloud/docs/gardener/shoot-operations/shoot_credentials_rotation/#serviceaccount-token-signing-key) -for the operational rotation procedure. +For detailed information about STACKIT Workload Identity, see the [STACKIT documentation](https://docs.stackit.cloud/products/runtime/kubernetes-engine/how-tos/workload-identity/). -## References +### References -- [STACKIT Workload Identity](https://docs.stackit.cloud/products/runtime/kubernetes-engine/how-tos/workload-identity/) - [STACKIT Service Account Federation](https://docs.stackit.cloud/platform/access-and-identity/service-accounts/how-tos/manage-service-account-federations/) - [`stackit-pod-identity-webhook`](https://github.com/stackitcloud/stackit-pod-identity-webhook) - [Gardener Managed Service Account Issuer](https://gardener.cloud/docs/gardener/security/shoot_serviceaccounts/#managed-service-account-issuer) From 639cec529788f1e19c0431b6af46c88f0e0d2041 Mon Sep 17 00:00:00 2001 From: Aniruddha Basak Date: Thu, 20 Aug 2026 12:35:01 +0200 Subject: [PATCH 3/9] add alb doc --- docs/usage/usage.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/docs/usage/usage.md b/docs/usage/usage.md index ae32aa92..74702a43 100644 --- a/docs/usage/usage.md +++ b/docs/usage/usage.md @@ -66,3 +66,39 @@ For detailed information about STACKIT Workload Identity, see the [STACKIT docum - [`stackit-pod-identity-webhook`](https://github.com/stackitcloud/stackit-pod-identity-webhook) - [Gardener Managed Service Account Issuer](https://gardener.cloud/docs/gardener/security/shoot_serviceaccounts/#managed-service-account-issuer) - [Kubernetes ServiceAccount token projection](https://kubernetes.io/docs/concepts/storage/projected-volumes/#serviceaccounttoken) + + +## STACKIT Application Load Balancer + +This extension automatically deploys and configures the STACKIT Application Load Balancer (ALB) Controller in your SKE cluster's control plane, enabling workloads to create Application Load Balancers using Kubernetes `Ingress` resources. + +### What this extension provides + +- Automatic deployment of the STACKIT ALB Controller in the Shoot control plane +- Support for creating Application Load Balancers from Kubernetes `Ingress` resources +- Deployment of the ALB validating webhook + +No manual ALB Controller installation is required — the extension handles this for you. + +### Quick start + +**Prerequisites:** + +- An SKE cluster with the Application Load Balancer extension enabled +- A Kubernetes `Ingress` resource + +### Enable the extension + +The Application Load Balancer extension is enabled through the SKE API: + +```yaml +extensions: + applicationLoadBalancer: + enabled: true +``` + +Ingress support is enabled automatically when the Application Load Balancer extension is enabled. + +### Learn more + +For more information about the STACKIT Application Load Balancer Controller, see the [`application-load-balancer-controller`](https://github.com/stackitcloud/application-load-balancer-controller) repository. From bae50dc5fb841300db1505b23023fb8e9ae0d61a Mon Sep 17 00:00:00 2001 From: Aniruddha Basak Date: Fri, 21 Aug 2026 11:44:31 +0200 Subject: [PATCH 4/9] fix alb doc and have migration instructions --- docs/usage/usage.md | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/docs/usage/usage.md b/docs/usage/usage.md index 74702a43..9181259c 100644 --- a/docs/usage/usage.md +++ b/docs/usage/usage.md @@ -72,20 +72,9 @@ For detailed information about STACKIT Workload Identity, see the [STACKIT docum This extension automatically deploys and configures the STACKIT Application Load Balancer (ALB) Controller in your SKE cluster's control plane, enabling workloads to create Application Load Balancers using Kubernetes `Ingress` resources. -### What this extension provides - -- Automatic deployment of the STACKIT ALB Controller in the Shoot control plane -- Support for creating Application Load Balancers from Kubernetes `Ingress` resources -- Deployment of the ALB validating webhook - -No manual ALB Controller installation is required — the extension handles this for you. - ### Quick start -**Prerequisites:** - -- An SKE cluster with the Application Load Balancer extension enabled -- A Kubernetes `Ingress` resource +Refer to [usage doc](https://github.com/stackitcloud/application-load-balancer-controller/blob/main/docs/user.md) of Application Load Balancer for setup. ### Enable the extension @@ -95,10 +84,16 @@ The Application Load Balancer extension is enabled through the SKE API: extensions: applicationLoadBalancer: enabled: true + ingress: + enabled: true ``` -Ingress support is enabled automatically when the Application Load Balancer extension is enabled. +NOTE: Ingress support needs to be enabled in order to use Application Load Balancer extension. ### Learn more For more information about the STACKIT Application Load Balancer Controller, see the [`application-load-balancer-controller`](https://github.com/stackitcloud/application-load-balancer-controller) repository. + +# Migrate from Openstack to STACKIT provider + +We still have openstack code runnnig in the repository, and in future it will be fully migrated and use stackit provider. From 0ce7fbc43b5c1f205ea645a104edacd84cbe9a3e Mon Sep 17 00:00:00 2001 From: Aniruddha Basak Date: Fri, 21 Aug 2026 13:16:51 +0200 Subject: [PATCH 5/9] add cloudprofile doc --- docs/operations/operations.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 docs/operations/operations.md diff --git a/docs/operations/operations.md b/docs/operations/operations.md new file mode 100644 index 00000000..c58550b7 --- /dev/null +++ b/docs/operations/operations.md @@ -0,0 +1,22 @@ +# Using the STACKIT provider extension with Gardener as operator + +The [`core.gardener.cloud/v1beta1.CloudProfile` resource](https://github.com/gardener/gardener/blob/master/example/30-cloudprofile.yaml) declares a `providerConfig` field that is meant to contain provider-specific configuration. + +In this document we are describing how this configuration looks like for STACKIT and provide an example `CloudProfile` manifest with minimal configuration that you can use to allow creating STACKIT shoot clusters. + + +## `CloudProfileConfig` + +The cloud profile configuration contains information about the real machine image IDs in the STACKIT environment (image names). +You have to map every version that you specify in `.spec.machineImages[].versions` here such that the STACKIT extension knows the image ID for every version you want to offer. + +TODO: ask about storageclass + +It also contains optional default values for DNS servers that shall be used for shoots. +In the `dnsServers[]` list you can specify IP addresses that are used as DNS configuration for created shoot subnets. + +Some hypervisors (especially those which are VMware-based) don't automatically send a new volume size to a Linux kernel when a volume is resized and in-use. +For those hypervisors you can enable the storage plugin interacting with Cinder to telling the SCSI block device to refresh its information to provide information about it's updated size to the kernel. You might need to enable this behavior depending on the underlying hypervisor of your STACKIT installation. The `rescanBlockStorageOnResize` field controls this. Please note that it only applies for Kubernetes versions where CSI is used. + +You can specify API endpoints for various STACKIT services(IaaS, LoadBalancer), via `APIEndpoints`. + From bfd95534f0a96a3d2fceabb553d2ea9b8fda78c9 Mon Sep 17 00:00:00 2001 From: Aniruddha Basak Date: Fri, 21 Aug 2026 13:19:55 +0200 Subject: [PATCH 6/9] update cloudprofile doc --- docs/operations/operations.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/operations/operations.md b/docs/operations/operations.md index c58550b7..c0cfb813 100644 --- a/docs/operations/operations.md +++ b/docs/operations/operations.md @@ -20,3 +20,5 @@ For those hypervisors you can enable the storage plugin interacting with Cinder You can specify API endpoints for various STACKIT services(IaaS, LoadBalancer), via `APIEndpoints`. +## Example `CloudProfile` manifest + From c0fe6e7ec83f84df4adb4f352d8b001695ec2fed Mon Sep 17 00:00:00 2001 From: Aniruddha Basak Date: Fri, 21 Aug 2026 13:22:17 +0200 Subject: [PATCH 7/9] update cloudprofile doc --- docs/operations/operations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/operations/operations.md b/docs/operations/operations.md index c0cfb813..162c6ea7 100644 --- a/docs/operations/operations.md +++ b/docs/operations/operations.md @@ -10,7 +10,7 @@ In this document we are describing how this configuration looks like for STACKIT The cloud profile configuration contains information about the real machine image IDs in the STACKIT environment (image names). You have to map every version that you specify in `.spec.machineImages[].versions` here such that the STACKIT extension knows the image ID for every version you want to offer. -TODO: ask about storageclass +TODO: ask about storageclass, where can i find what type of storage class exist and what imp thing to mention. It also contains optional default values for DNS servers that shall be used for shoots. In the `dnsServers[]` list you can specify IP addresses that are used as DNS configuration for created shoot subnets. From 0363b0f03d53ba97c1f9c536279af0d9febcb5fc Mon Sep 17 00:00:00 2001 From: Aniruddha Basak Date: Fri, 21 Aug 2026 15:10:05 +0200 Subject: [PATCH 8/9] add cloudprofile example --- docs/operations/operations.md | 45 +++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/docs/operations/operations.md b/docs/operations/operations.md index 162c6ea7..d29e6054 100644 --- a/docs/operations/operations.md +++ b/docs/operations/operations.md @@ -22,3 +22,48 @@ You can specify API endpoints for various STACKIT services(IaaS, LoadBalancer), ## Example `CloudProfile` manifest +The following example shows a minimal `CloudProfile` configuration for STACKIT: + +```yaml +apiVersion: core.gardener.cloud/v1beta1 +kind: CloudProfile +metadata: + name: stackit +spec: + type: stackit + kubernetes: + versions: + - version: 1.35.6 + machineImages: + - name: coreos + versions: + - version: 4593.2.2 + architectures: + - amd64 + machineTypes: + - name: g1.2 + cpu: "2" + gpu: "0" + memory: 8Gi + architecture: amd64 + storage: + class: storage_premium_perf1 + type: storage_premium_perf1 + size: 50Gi + regions: + - name: RegionOne + zones: + - name: eu01-1 + providerConfig: + apiVersion: stackit.provider.extensions.gardener.cloud/v1alpha1 + kind: CloudProfileConfig + machineImages: + - name: coreos + versions: + - version: 4593.2.2 + regions: + - name: RegionOne + architecture: amd64 + id: + storageClasses: TODO: add it after clarification. + From 4fe7a86a644b1db1659384f7960b62ae222741e0 Mon Sep 17 00:00:00 2001 From: Aniruddha Basak Date: Sun, 23 Aug 2026 16:53:46 +0200 Subject: [PATCH 9/9] update enable extension part --- docs/usage/usage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/usage/usage.md b/docs/usage/usage.md index 9181259c..65ffeb01 100644 --- a/docs/usage/usage.md +++ b/docs/usage/usage.md @@ -78,7 +78,7 @@ Refer to [usage doc](https://github.com/stackitcloud/application-load-balancer-c ### Enable the extension -The Application Load Balancer extension is enabled through the SKE API: +The Application Load Balancer extension can be enables by ControlPlaneConfig of the shoot: ```yaml extensions: