|
1 | 1 | ---
|
2 |
| -title: Deploy and configure Workload Identity on an AKS Edge Essentials cluster (preview) |
3 |
| -description: Learn how to deploy and configure an AKS Edge Essentials cluster with workload identity. |
| 2 | +title: Configure Workload Identity on an AKS Edge Essentials cluster (preview) |
| 3 | +description: Learn how to configure an AKS Edge Essentials cluster with workload identity. |
4 | 4 | author: sethmanheim
|
5 | 5 | ms.author: sethm
|
6 | 6 | ms.topic: how-to
|
7 | 7 | ms.date: 11/12/2024
|
8 | 8 |
|
9 | 9 | ---
|
10 | 10 |
|
11 |
| -# Deploy and configure Workload Identity on an AKS Edge Essentials cluster (preview) |
12 |
| - |
13 |
| -[!INCLUDE [hci-applies-to-23h2](includes/hci-applies-to-23h2.md)] |
| 11 | +# Configure Workload Identity on an AKS Edge Essentials cluster (preview) |
14 | 12 |
|
15 | 13 | Azure Kubernetes Service (AKS) Edge Essentials is an on-premises Kubernetes implementation of Azure Kubernetes Service (AKS) that automates running containerized applications at scale. This article describes how to perform the following tasks:
|
16 | 14 |
|
17 | 15 | - Create a Kubernetes service account and bind it to the Azure Managed Identity.
|
18 | 16 | - Create a federated credential on the managed identity to trust the OIDC issuer.
|
19 |
| -- Optional: Grant a pod in the cluster access to secrets in an Azure key vault. |
20 | 17 | - Deploy your application.
|
| 18 | +- Example: Grant a pod in the cluster access to secrets in an Azure key vault. |
21 | 19 |
|
22 |
| -<!-- For a conceptual overview of using Workload Identity federation with Azure Arc-enabled Kubernetes clusters, see [Deploy and configure Workload Identity on an AKS enabled by Azure Arc cluster (preview)](workload-identity.md). --> |
| 20 | +For a conceptual overview of using Workload identity federation, see [Workload identity federation in Azure Arc-enabled Kubernetes](azure/azure-arc/kubernetes/conceptual-workload-identity.md). |
23 | 21 |
|
24 | 22 | > [!IMPORTANT]
|
25 | 23 | > These preview features are available on a self-service, opt-in basis. Previews are provided "as is" and "as available," and they're excluded from the service-level agreements and limited warranty. Azure Kubernetes Service Edge Essentials previews are partially covered by customer support on a best-effort basis.
|
@@ -151,7 +149,43 @@ az identity federated-credential show --name $FedIdCredentialName --resource-gro
|
151 | 149 | > [!NOTE]
|
152 | 150 | > After you add a federated identity credential, it takes a few seconds to propagate. Token requests made immediately afterward might fail until the cache refreshes. To prevent this issue, consider adding a brief delay after creating the federated identity credential.
|
153 | 151 |
|
154 |
| -## Optional: Grant permissions to access Azure Key Vault |
| 152 | + |
| 153 | +## Step 3: Deploy your application |
| 154 | + |
| 155 | +When you deploy your application pods, the manifest should reference the service account created in the **Create Kubernetes service account** step. The following manifest shows how to reference the account, specifically the `metadata\namespace` and `spec\serviceAccountName` properties. Make sure to specify an image for `image` and a container name |
| 156 | +for `containerName`: |
| 157 | + |
| 158 | +```azurecli |
| 159 | +$image = "<image>" # Replace <image> with the actual image name |
| 160 | +$containerName = "<containerName>" # Replace <containerName> with the actual container name |
| 161 | +
|
| 162 | +$yaml = @" |
| 163 | +apiVersion: v1 |
| 164 | +kind: Pod |
| 165 | +metadata: |
| 166 | + name: sample-quick-start |
| 167 | + namespace: $SERVICE_ACCOUNT_NAMESPACE |
| 168 | + labels: |
| 169 | + azure.workload.identity/use: "true" # Required. Only pods with this label can use workload identity. |
| 170 | +spec: |
| 171 | + serviceAccountName: $SERVICE_ACCOUNT_NAME |
| 172 | + containers: |
| 173 | + - image: $image |
| 174 | + name: $containerName |
| 175 | +"@ |
| 176 | +
|
| 177 | +# Replace variables within the YAML content |
| 178 | +$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` |
| 179 | + -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME |
| 180 | +
|
| 181 | +# Apply the YAML configuration |
| 182 | +$yaml | kubectl apply -f - |
| 183 | +``` |
| 184 | + |
| 185 | +> [!IMPORTANT] |
| 186 | +> Ensure that the application pods using workload identity include the label `azure.workload.identity/use: "true"` in the pod spec. Otherwise the pods fail after they restart. |
| 187 | +
|
| 188 | +## Example: Grant permissions to access Azure Key Vault |
155 | 189 |
|
156 | 190 | The instructions in this step describe how to access secrets, keys, or certificates in an Azure key vault from the pod. The examples in this section configure access to secrets in the key vault for the workload identity, but you can perform similar steps to configure access to keys or certificates.
|
157 | 191 |
|
@@ -225,41 +259,6 @@ The following example shows how to use the Azure role-based access control (Azur
|
225 | 259 | $yaml | kubectl --kubeconfig $aks_cluster_name apply -f -
|
226 | 260 | ```
|
227 | 261 |
|
228 |
| -## Step 3: Deploy your application |
229 |
| - |
230 |
| -When you deploy your application pods, the manifest should reference the service account created in the **Create Kubernetes service account** step. The following manifest shows how to reference the account, specifically the `metadata\namespace` and `spec\serviceAccountName` properties. Make sure to specify an image for `image` and a container name |
231 |
| -for `containerName`: |
232 |
| - |
233 |
| -```azurecli |
234 |
| -$image = "<image>" # Replace <image> with the actual image name |
235 |
| -$containerName = "<containerName>" # Replace <containerName> with the actual container name |
236 |
| -
|
237 |
| -$yaml = @" |
238 |
| -apiVersion: v1 |
239 |
| -kind: Pod |
240 |
| -metadata: |
241 |
| - name: sample-quick-start |
242 |
| - namespace: $SERVICE_ACCOUNT_NAMESPACE |
243 |
| - labels: |
244 |
| - azure.workload.identity/use: "true" # Required. Only pods with this label can use workload identity. |
245 |
| -spec: |
246 |
| - serviceAccountName: $SERVICE_ACCOUNT_NAME |
247 |
| - containers: |
248 |
| - - image: $image |
249 |
| - name: $containerName |
250 |
| -"@ |
251 |
| -
|
252 |
| -# Replace variables within the YAML content |
253 |
| -$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` |
254 |
| - -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME |
255 |
| -
|
256 |
| -# Apply the YAML configuration |
257 |
| -$yaml | kubectl apply -f - |
258 |
| -``` |
259 |
| - |
260 |
| -> [!IMPORTANT] |
261 |
| -> Ensure that the application pods using workload identity include the label `azure.workload.identity/use: "true"` in the pod spec. Otherwise the pods fail after they restart. |
262 |
| -
|
263 | 262 | ## Next steps
|
264 | 263 |
|
265 |
| -In this article, you deployed a Kubernetes cluster and configured it to use a workload identity in preparation for application workloads to authenticate with that credential. Now you're ready to deploy your application and configure it to use the workload identity with the latest version of the [Azure Identity client library](/azure/active-directory/develop/reference-v2-libraries). |
| 264 | +In this article, you configured it to use a workload identity in preparation for application workloads to authenticate with that credential. Now you're ready to deploy your application and configure it to use the workload identity with the latest version of the [Azure Identity client library](/azure/active-directory/develop/reference-v2-libraries). |
0 commit comments