github.com/ironcore-dev/gardener-extension-provider-ironcore@v0.3.2-0.20240314231816-8336447fb9a0/docs/operations/deployment.md (about) 1 # Deployment of the ironcore provider extension 2 3 **Disclaimer:** This document is NOT a step-by-step installation guide for the `ironcore` provider extension and only 4 contains some configuration specifics regarding the installation of different components via the helm charts residing 5 in the ironcore provider extension [repository](https://github.com/gardener/gardener-extension-provider-ironcore). 6 7 ## gardener-extension-admission-ironcore 8 9 ### Authentication against the Garden cluster 10 11 There are several authentication possibilities depending on whether [the concept of *Virtual Garden*](https://github.com/gardener/garden-setup#concept-the-virtual-cluster) is used. 12 13 #### *Virtual Garden* is not used, i.e., the `runtime` Garden cluster is also the `target` Garden cluster. 14 15 **Automounted Service Account Token** 16 The easiest way to deploy the `gardener-extension-admission-ironcore` component will be to not provide `kubeconfig` at 17 all. This way in-cluster configuration and an automounted service account token will be used. The drawback of this 18 approach is that the automounted token will not be automatically rotated. 19 20 **Service Account Token Volume Projection** 21 Another solution will be to use [Service Account Token Volume Projection](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) combined with a `kubeconfig` referencing 22 a token file (see example below). 23 24 ```yaml 25 apiVersion: v1 26 kind: Config 27 clusters: 28 - cluster: 29 certificate-authority-data: <CA-DATA> 30 server: https://default.kubernetes.svc.cluster.local 31 name: garden 32 contexts: 33 - context: 34 cluster: garden 35 user: garden 36 name: garden 37 current-context: garden 38 users: 39 - name: garden 40 user: 41 tokenFile: /var/run/secrets/projected/serviceaccount/token 42 ``` 43 44 This will allow for automatic rotation of the service account token by the `kubelet`. The configuration can be achieved 45 by setting both `.Values.global.serviceAccountTokenVolumeProjection.enabled: true` and `.Values.global.kubeconfig` in 46 the respective chart's `values.yaml` file. 47 48 #### *Virtual Garden* is used, i.e., the `runtime` Garden cluster is different from the `target` Garden cluster. 49 50 **Service Account** 51 The easiest way to set up the authentication will be to create a service account and the respective roles will be bound 52 to this service account in the `target` cluster. Then use the generated service account token and craft a `kubeconfig` 53 which will be used by the workload in the `runtime` cluster. This approach does not provide a solution for the rotation 54 of the service account token. However, this setup can be achieved by setting `.Values.global.virtualGarden.enabled: true` 55 and following these steps: 56 57 1. Deploy the `application` part of the charts in the `target` cluster. 58 2. Get the service account token and craft the `kubeconfig`. 59 3. Set the crafted `kubeconfig` and deploy the `runtime` part of the charts in the `runtime` cluster. 60 61 **Client Certificate** 62 Another solution will be to bind the roles in the `target` cluster to a `User` subject instead of a service account and 63 use a client certificate for authentication. This approach does not provide a solution for the client certificate 64 rotation. However, this setup can be achieved by setting both `.Values.global.virtualGarden.enabled: true` 65 and `.Values.global.virtualGarden.user.name`, then following these steps: 66 67 1. Generate a client certificate for the `target` cluster for the respective user. 68 2. Deploy the `application` part of the charts in the `target` cluster. 69 3. Craft a `kubeconfig` using the already generated client certificate. 70 4. Set the crafted `kubeconfig` and deploy the `runtime` part of the charts in the `runtime` cluster. 71 72 **Projected Service Account Token** 73 This approach requires an already deployed and configured [oidc-webhook-authenticator](https://github.com/gardener/oidc-webhook-authenticator) for the `target` cluster. 74 Also, the `runtime` cluster should be registered as a trusted identity provider in the `target` cluster. Then projected 75 service accounts tokens from the `runtime` cluster can be used to authenticate against the `target` cluster. 76 The needed steps are as follows: 77 78 1. Deploy [OWA](https://github.com/gardener/oidc-webhook-authenticator) and establish the needed trust. 79 2. Set `.Values.global.virtualGarden.enabled: true` and `.Values.global.virtualGarden.user.name`. **Note:** username value will depend on the trust configuration, e.g., `<prefix>:system:serviceaccount:<namespace>:<serviceaccount>` 80 3. Set `.Values.global.serviceAccountTokenVolumeProjection.enabled: true` and `.Values.global.serviceAccountTokenVolumeProjection.audience`. **Note:** audience value will depend on the trust configuration, e.g., `<cliend-id-from-trust-config>`. 81 4. Craft a kubeconfig (see example below). 82 5. Deploy the `application` part of the charts in the `target` cluster. 83 6. Deploy the `runtime` part of the charts in the `runtime` cluster. 84 85 ```yaml 86 apiVersion: v1 87 kind: Config 88 clusters: 89 - cluster: 90 certificate-authority-data: <CA-DATA> 91 server: https://virtual-garden.api 92 name: virtual-garden 93 contexts: 94 - context: 95 cluster: virtual-garden 96 user: virtual-garden 97 name: virtual-garden 98 current-context: virtual-garden 99 users: 100 - name: virtual-garden 101 user: 102 tokenFile: /var/run/secrets/projected/serviceaccount/token 103 ```