Non-tested support for azure challenge 11

Author: bendehaan

azure/iam.tf

@@ -18,6 +18,12 @@ resource "azurerm_role_assignment" "aks_identity_operator" {
   principal_id         = azurerm_kubernetes_cluster.cluster.kubelet_identity[0].object_id
 }
 
+resource "azurerm_role_assignment" "aks_extra_identity_operator" {
+  scope                = azurerm_user_assigned_identity.aks_extra_pod_identity.id
+  role_definition_name = "Managed Identity Operator"
+  principal_id         = azurerm_kubernetes_cluster.cluster.kubelet_identity[0].object_id
+}
+
 resource "azurerm_role_assignment" "aks_vm_contributor" {
   scope                = "/subscriptions/${data.azurerm_client_config.current.subscription_id}/resourcegroups/${azurerm_kubernetes_cluster.cluster.node_resource_group}"
   role_definition_name = "Virtual Machine Contributor"

azure/k8s-vault-azure-start.sh

@@ -19,6 +19,7 @@ checkCommandsAvailable helm minikube jq vault sed grep docker grep cat az envsub
 echo "This is a script to bootstrap the configuration. You need to have installed: helm, kubectl, jq, vault, grep, cat, sed, envsubst, and azure cli, and is only tested on mac, Debian and Ubuntu"
 echo "This script is based on the steps defined in https://learn.hashicorp.com/tutorials/vault/kubernetes-minikube. Vault is awesome!"
 
+# Most of the variables below are used in envsubst later.
 export AZURE_SUBSCRIPTION_ID="$(az account show --query id --output tsv)"
 export AZURE_TENANT_ID="$(az account show --query tenantId --output tsv)"
 
@@ -31,6 +32,10 @@ export IDENTITY_NAME="wrongsecrets-identity"
 
 export AZ_POD_RESOURCE_ID="$(terraform output -raw aad_pod_identity_resource_id)"
 export AZ_POD_CLIENT_ID="$(terraform output -raw aad_pod_identity_client_id)"
+
+export AZ_EXTRA_POD_RESOURCE_ID="$(terraform output -raw aad_extra_pod_identity_resource_id)"
+export AZ_EXTRA_POD_CLIENT_ID="$(terraform output -raw aad_extra_pod_identity_client_id)"
+
 export AZ_VAULT_URI="$(terraform output -raw vault_uri)"
 export AZ_KEY_VAULT_TENANT_ID="$(terraform output -raw tenant_id)"
 export AZ_KEY_VAULT_NAME="$(terraform output -raw vault_name)"

azure/k8s/pod-id.yml.tpl

@@ -14,3 +14,20 @@ metadata:
 spec:
   azureIdentity: wrongsecrets-pod-id
   selector: wrongsecrets-pod-id
+---
+apiVersion: "aadpodidentity.k8s.io/v1"
+kind: AzureIdentity
+metadata:
+  name: separate-workload-pod-id
+spec:
+  type: 0
+  resourceID: ${AZ_EXTRA_POD_RESOURCE_ID}
+  clientID: ${AZ_EXTRA_POD_CLIENT_ID}
+---
+apiVersion: "aadpodidentity.k8s.io/v1"
+kind: AzureIdentityBinding
+metadata:
+  name: wrongsecrets-extra-podid-binding
+spec:
+  azureIdentity: separate-workload-pod-id
+  selector: separate-workload-pod-id

azure/outputs.tf

@@ -23,6 +23,16 @@ output "aad_pod_identity_client_id" {
   description = "Client ID for the Managed Identity for AAD Pod Identity"
 }
 
+output "aad_extra_pod_identity_resource_id" {
+  value       = azurerm_user_assigned_identity.aks_extra_pod_identity.id
+  description = "Resource ID for the Managed Identity for AAD Pod Identity"
+}
+
+output "aad_extra_pod_identity_client_id" {
+  value       = azurerm_user_assigned_identity.aks_extra_pod_identity.client_id
+  description = "Client ID for the Managed Identity for AAD Pod Identity"
+}
+
 output "vault_uri" {
   value       = azurerm_key_vault.vault.vault_uri
   description = "Vault URI"

azure/secrets.tf

@@ -3,7 +3,7 @@
 #########################
 
 resource "random_integer" "suffix" {
-  min = 11111
+  min = 00000
   max = 99999
 }
 
@@ -92,6 +92,8 @@ resource "azurerm_key_vault_secret" "wrongsecret_3" {
   ]
 }
 
+# With Azure key vault, you grant access per vault instead of per secret. Below is a bad idea if these workloads should
+# be separated
 resource "azurerm_key_vault_access_policy" "extra_identity_access" {
   key_vault_id = azurerm_key_vault.vault.id
   tenant_id    = data.azurerm_client_config.current.tenant_id

src/main/resources/explanations/challenge11-azure.adoc

@@ -1,11 +1,7 @@
 === Azure Key Vault part 3
 
-In our GKE cluster, there's a service account for workloads, which maps to a service account in kubernetes. 
+In our AKS cluster, there are two Azure Identity bindings. These are used by Azure to inject metadata. In our case, we use these to access Azure Key Vault.
 
-Unfortunately the developers used only one GCP service account to bind to multiple K8s service accounts. This means a different pod can access our secrets... 
+The interesting thing about key vault is that it sets permissions per vault, rather than per secret. The developers unfortunately only have one key vault for two identities...
 
-Try provisioning `wrongsecret-3` with a pod with the `default` service account in the default namespace.
-
-
-Hint: You could use a job with the image `gcr.io/google.com/cloudsdktool/cloud-sdk:latest` and use the `gcloud` cli.
-See https://cloud.google.com/secret-manager/docs/creating-and-accessing-secrets#a_note_on_resource_consistency[accessing a secret] for some help.
+Hint: There's a binding to `separate-workload-pod-id`. Try creating a pod with the right labels to steal wrongsecret-3 (see also[https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity#run-a-sample-application]).

src/main/resources/explanations/challenge11-azure_hint.adoc

@@ -1,32 +1,27 @@
 You can solve this challenge by the following steps:
 
-- Create a new job file `job.yaml` with the following content:
+- Check your vault name with `terraform output vault_name`.
+
+- Create a new pod file `pod.yaml` with the following content (replace the vault name with output from the previous step):
 
 ```yaml
 apiVersion: batch/v1
 kind: Job
 metadata:
   name: wrongsecret-3
+  labels:
+    aadpodidbinding: separate-workload-pod-id
 spec:
   template:
     spec:
-      serviceAccountName: default
       containers:
-        - name: gcloud
-          image: gcr.io/google.com/cloudsdktool/cloud-sdk:latest
-          command:
-            [
-              "gcloud",
-              "secrets",
-              "versions",
-              "access",
-              "latest",
-              "--secret=wrongsecret-3",
-            ]
+        - name: az
+          image: mcr.microsoft.com/azure-cli:latest
+          command: ["az", "keyvault", "secret", "show", "--name=wrongsecret-3", "--vault-name=YOUR_VAULT_NAME_HERE"]
       restartPolicy: Never
 ```
 
-This job executes the command `gcloud secrets versions access latest --secret=wrongsecret-3`. Since the job can access the same service account as the secret challenge pod, it can access GCP with the same privileges.
+This job executes something like the command `az keyvault secret show --name wrongsecret-3 --vault-name wrongsecrets-vault-00000`. Since the job can access the same vault as the secret challenge pod, it has access to its secrets.
 
 - Apply the job with `kubectl apply -f job.yaml`
 - Check the job's logs with `kubectl logs job/wrongsecret-3`. This should show you the solution :)

src/main/resources/explanations/challenge11-azure_reason.adoc

@@ -2,4 +2,4 @@ Secrets management is more than secure storage:
 
 As you can tell by now: there are many ways to get to a secret: whether hardcoded, stored in a misconfigured third party solution, or stored correctly, but with the wrong IAM access rights in accounts next to it. You will, by now see, why we say that "your security maturity reflects in your secrets management".
 
-In this specific case, it would be a bad idea to have this kind of production access without triggering some "break glass" procedure and appropriate alarms. Additionally, anything that explicitly logs secrets is dangerous. If you spot any code logging secrets, flag it!
+In this specific case two separate workloads were able to access each other's secrets. This could have been prevented by creating different key vaults for different purposes.