Uitwerking

4.1 Helm

Helm is de pakketbeheerder voor Kubernetes. In plaats van handmatig losse YAML-bestanden toe te passen, bundelt Helm alles in een chart.

Er zijn drie kernconcepten:

1. Een chart is een bundel met alle informatie die nodig is om een Kubernetes-applicatie te installeren.
2. De config (values.yaml) bevat configuratie die samengevoegd kan worden met een chart.
3. Een release is een draaiende instantie van een chart gecombineerd met specifieke configuratie.

Installatie via de officiële Helm docs.

a) Standaard chart

Cluster aanmaken:

Een Autopilot GKE-cluster aangemaakt: week4-cluster.

gcloud container clusters get-credentials week4-cluster --region=europe-west4

gcloud container clusters get-credentials week4-cluster --region=europe-west4

Helm chart aanmaken:

helm create public-cloud-concepts

Chartstructuur:

• charts/ - afhankelijkheden (standaard leeg)
• templates/ - Kubernetes YAML-bestanden met variabelen uit values.yaml
• Chart.yaml - metadata (naam, versie, beschrijving)
• values.yaml - standaard configuratiewaarden

Standaardwaarden: replicaCount: 1, image nginx, service.type: ClusterIP, Ingress uitgeschakeld.

Installeren als v1:

helm install public-cloud-concepts-v1 public-cloud-concepts

Aanpassen naar v2:

Twee waarden aangepast in values.yaml:

-replicaCount: 1
+replicaCount: 2

 ingress:
-  enabled: false
+  enabled: true

helm upgrade public-cloud-concepts-v1 public-cloud-concepts

helm history public-cloud-concepts-v1
# REVISION 1: superseded
# REVISION 2: deployed

Rollback:

helm rollback public-cloud-concepts-v1 1

Verwijderen:

helm uninstall public-cloud-concepts-v1

b) Eigen applicatie

De static-site chart gebruikt het Docker-image uit Week 1 en 2. In values.yaml is het standaard nginx-image vervangen:

 image:
-  repository: nginx
+  repository: stensel8/public-cloud-concepts
+  tag: "latest"

helm install static-site-v1 ./static-site

kubectl port-forward svc/static-site-v1 8080:80

c) WordPress via Bitnami

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

De standaard helm install bitnami/wordpress werkt niet direct op GKE Autopilot. Drie problemen:

helm install my-wordpress bitnami/wordpress \
    --set wordpressUsername=admin \
    --set wordpressPassword=MijnWachtwoord123 \
    --set wordpressEmail=[email protected] \
    --set wordpressBlogName="Mijn Blog" \
    --set resources.requests.ephemeral-storage=1Gi \
    --set resources.limits.ephemeral-storage=2Gi \
    --set resources.requests.memory=256Mi \
    --set resources.requests.cpu=100m \
    --set mariadb.primary.resources.requests.ephemeral-storage=1Gi \
    --set mariadb.primary.resources.limits.ephemeral-storage=2Gi \
    --set mariadb.primary.resources.requests.memory=256Mi \
    --set mariadb.primary.resources.requests.cpu=100m

Service ontbrak na installatie, handmatig aangemaakt:

helm get manifest my-wordpress | awk '/Source: wordpress\/templates\/svc.yaml/,/^---/' | kubectl apply -f -

Opruimen:

helm uninstall my-wordpress
kubectl delete pvc --selector app.kubernetes.io/instance=my-wordpress
gcloud container clusters delete week4-cluster --region=europe-west4

4.2 IAM & Casestudy: EHR Healthcare

EHR Healthcare is een bedrijf met een on-premise infrastructuur dat wil migreren naar de cloud. Ze zijn geïnteresseerd in beveiliging en IAM. Per gevraagd concept heb ik uitgelegd wat het is en waarom ik het zou aanbevelen voor dit bedrijf.

1. Single Sign-On (SSO)

SSO betekent dat je één keer inlogt en daarna toegang hebt tot meerdere applicaties zonder elke keer opnieuw te authenticeren. In Azure gaat dit via Microsoft Entra ID. Via Azure AD Application Proxy of SAML-integratie werkt dit ook voor on-premise applicaties.

Voor EHR zou ik dit zeker inzetten. Minder losse wachtwoorden betekent minder phishing-risico, en medewerkers hoeven niet voor elke applicatie een apart account bij te houden.

2. Conditional Access

Conditional Access is beleid dat bepaalt onder welke omstandigheden toegang wordt verleend, zoals alleen vanaf beheerde apparaten of MFA vereisen bij inloggen vanuit een onbekend land.

Voor EHR is dit essentieel. Ze werken met gevoelige patiëntgegevens, dus toegang mag niet puur afhangen van een wachtwoord. Locatie, apparaat en risiconiveau moeten ook meewegen.

3. RBAC (Role-Based Access Control)

Met RBAC wijs je rechten toe op basis van rollen in plaats van individuele gebruikers. In Azure werkt dit op abonnementsniveau, resource group-niveau of resource-niveau.

Voor een gecontroleerde migratie is dit essentieel. Door rollen vooraf te definiëren (bijv. “Database-beheerder”, “Applicatiebeheerder”) blijft het beheer overzichtelijk en gaan rechten automatisch mee bij personeelswisselingen.

4. Identity Protection

Microsoft Entra Identity Protection detecteert riskante inlogpogingen automatisch, zoals aanmeldingen vanuit anonieme IP-adressen, onmogelijke reizen (inloggen vanuit Amsterdam en Tokyo binnen een uur), of gelekte wachtwoorden.

De meeste aanvallen beginnen met gecompromitteerde inloggegevens. Identity Protection detecteert dit en kan automatisch MFA afdwingen of accounts blokkeren. Voor EHR zou ik dit zeker inzetten.

5. Multi-Factor Authentication (MFA)

MFA is een tweede verificatiestap naast het wachtwoord, zoals een authenticator-app, sms of hardware token.

Voor EHR zou ik dit verplicht stellen voor alle medewerkers. MFA blokkeert het overgrote deel van account-aanvallen, ook als een wachtwoord uitgelekt is. Voor healthcare is dit gewoon een basismaatregel.

6. Managed Identities en Service Principals

Managed Identities zijn Azure-beheerde identiteiten voor applicaties en services. Geen wachtwoord nodig; Azure regelt de credentials automatisch. Service Principals zijn de handmatige variant waarbij je zelf credentials beheert.

Voor cloud-native applicaties is Managed Identity de betere keuze. Geen opgeslagen wachtwoorden in configuratiebestanden, automatische rotatie en directe integratie met Azure RBAC. Service Principals gebruik je alleen als een applicatie buiten Azure draait en Azure-resources moet benaderen.

4.2.2 Helm op Azure (AKS)

De Helm charts uit week 4 zijn ontwikkeld op GKE, maar ze werken ook op Azure Kubernetes Service (AKS). Helm is Kubernetes-native en werkt platform-onafhankelijk. Toch zijn er een paar praktische verschillen.

Storage classes

GKE gebruikt standard-rwo als standaard storage class. Op AKS is dat managed-csi (Azure Disk). Bij charts die persistent storage aanvragen, zoals WordPress, moet je de storage class expliciet instellen:

helm install my-wordpress bitnami/wordpress \
  --set global.storageClass=managed-csi

Dit is precies hetzelfde probleem als bij de monitoring stack in Week 5: het schoolscript gebruikte managed-csi omdat het op Azure was geschreven, wat op GKE niet werkt.

Authenticatie naar de container registry

Op GKE gebruik ik Artifact Registry met een service account key als GitHub Secret. Op Azure gebruik je Azure Container Registry (ACR). AKS kan je koppelen aan een ACR zonder losse credentials via een managed identity:

az aks update --name <cluster> --resource-group <rg> --attach-acr <acr-naam>

Dat is vergelijkbaar met hoe ik op GKE de Compute Engine default service account Artifact Registry Reader rechten geef voor de nodes.

Helm charts deployen via een pipeline op Azure

Voor EHR Healthcare zou ik dezelfde aanpak gebruiken als in Week 3, maar dan met Azure-specifieke stappen:

De Helm charts zelf hoeven nauwelijks aan te passen. Het zijn vooral de CI/CD pipeline en de storage class in values.yaml die platform-specifiek zijn.

Aanbeveling voor EHR Healthcare

Omdat EHR al met Azure AD werkt, zou ik kiezen voor AKS met Workload Identity. Dat koppelt de Managed Identity van een pod direct aan een Kubernetes service account, zonder losse credentials. De Helm charts blijven hetzelfde; de authenticatie wordt geregeld via Azure RBAC.