Kubernetes is een krachtige container orchestration tool die recentelijk aan populariteit heeft gewonnen. Naarmate organisaties Kubernetes aannemen, moeten ze nadenken over hoe ze hun resources het beste kunnen beveiligen. Een optie om Kubernetes workloads te authenticeren, is door gebruik te maken van OIDC.
OIDC (OpenID Connect) is een authenticatieprotocol dat voortbouwt op OAuth 2. Het stelt gebruikers in staat om zich te authenticeren bij een identity provider (zoals Google of Microsoft). In deze post zullen we bespreken wat de voordelen zijn van het authenticeren van Kubernetes workloads met OIDC, en hoe je OIDC authenticatie kunt instellen en configureren.
Zowel Kubernetes als OIDC zijn complexe onderwerpen. In de volgende alinea’s zal ik hier iets meer over vertellen. Na het lezen van deze post raad ik aan om de hulp links te bekijken.
Waarom zou ik Workload Identity overwegen?
Wat zijn de voordelen van het authenticeren van Kubernetes workloads met OIDC?
Er zijn verschillende voordelen, waaronder:
- Verbeterde beveiliging – OIDC biedt een hoger beveiligingsniveau dan traditionele gebruikersnaam/wachtwoord authenticatie schema’s.
- Verminderde complexiteit – OIDC zorgt ervoor dat wachtwoorden niet meer nodig zijn of dat certificaat rotatie nodig is.
- OIDC is een op standaarden gebaseerd protocol, wat betekent dat het compatibel is met een breed scala aan externe identiteitsproviders.
- Azure OIDC wordt ondersteund door Azure AD, dat beveiliging en betrouwbaarheid van enterprise-niveau biedt.
In tegenstelling tot een Azure Function waar je gemakkelijk een identiteit kunt binden, moet je in een andere externe resource (Kubernetes-cluster of een Github Action) een identiteit handmatig definiëren.
Wat is Azure AD workload identity?
Azure Active Directory workload identity is een functie die momenteel in de preview-fase zit terwijl ik deze regels schrijf. Deze authenticatiemethode integreert met native Kubernetes-functies om te federeren met elke externe identiteitsprovider. Deze aanpak is eenvoudiger in gebruik en implementatie en overwint verschillende beperkingen in Azure AD pod-managed identity (een andere aanpak is om een Azure-identiteit te definiëren voor workloads):
- Verwijdert de schaal- en prestatieproblemen die bestonden bij identiteits-toewijzing.
- Ondersteunt Kubernetes-clusters die zijn gehost in elke cloud of on-premises.
- Ondersteunt Linux- en Windows-workloads.
- Verwijdert de noodzaak voor Custom Resource Definitions en pods die Azure Instance Metadata Service (IMDS) verkeer onderscheppen.
Hieronder zie je hoe federated identities werken.
Uiteindelijk hoef je alleen Azure RBAC-machtigingen in te stellen om autorisaties te beheren.
Hoe je aan de slag kunt gaan met Azure AD workload identity met AKS.
Voor mij is de gemakkelijkste benadering om nieuwe dingen te leren, om ze te proberen te implementeren. Nadat alles op zijn plaats staat, begin ik alle kleine onderdelen te onderzoeken om dieper te gaan. Laten we dus een cluster implementeren.
Om Azure OIDC te gebruiken, heb je een Azure-abonnement nodig. Je kunt je aanmelden voor een gratis proefperiode of je bestaande Azure-abonnement gebruiken. Je moet ook een Azure Active Directory (AD) tenant maken. Indien je geen AD-tenant hebt, kun je er een aanmaken via het Azure-portal.
Bekijk de code op https://github.com/lucassc/aks-workload-identity en volg de stappen in het readme-bestand.
De Terraform-code zal het volgende creëren:
- AKS-cluster met ingeschakelde OIDC-issuer (aks.tf)
- Identiteit: App-registratie met service principe (app-identity.tf)
- Een Kubernetes-serviceaccount (app-identity.tf) voor de identiteit
- Application Federation tussen App-registratie en een Kubernetes-serviceaccount (app-identity.tf). Zie voor meer informatie: Workload identity federation
- Installeren van workload-identity-webhook helm chart. In de toekomst zal dit een AKS-addon zijn (helm_charts.tf). Zie voor meer informatie: Mutating Admission Webhook
- Azure Key Vault om de implementatie te testen (azure-key-vault.tf)
- Azure Key Vault-toegangsbeleid: om de identiteit in staat te stellen geheimen op te halen en te vermelden. (azure-key-vault.tf)
Na het uitvoeren van terraform apply (stap 1), hoef je alleen maar een nieuw geheim aan te maken (stap 2) en de voorbeeld toepassing te implementeren om de geheime waarden op te halen (stap 4).Hieronder zie je het verzoek resultaat met behulp van de Swagger IU, maar hetzelfde resultaat is mogelijk met een curl-commando. Het curl-commando vind je op de Github readme-pagina in Step 5.
Nu kun je zien dat, met alles op zijn plaats, op elk moment dat we een geheim aanraken om de vault-lezer in staat te stellen de geheimen op te halen uit de Azure Key Vault. Dezelfde aanpak kan worden gebruikt om te authenticeren tegen andere resources zoals Storage Accounts en Databases.
Voor dit voorbeeld heb ik een AKS-cluster gebruikt, maar dezelfde aanpak zal werken voor elke Kubernetes-cluster boven 1.20+. Workload identity kan werken met k8s-clusters op versie 1.18+, maar de aanbeveling is 1.20+.
Meer informatie
- Azure Github pagina’s: Introduction – Azure AD Workload Identity
- MS Docs: OpenID Connect (OIDC) on the Microsoft identity platform
- MS Docs: Use an Azure AD workload identities (preview) on Azure Kubernetes Service (AKS)
- Stop met het gebruiken van geheimen op Github actions, Youtube: GitHub Actions with Azure AD Workload Identity Federation.
Als je de stappen in deze post hebt gevolgd, zou je nu een Azure Kubernetes-cluster met workload identity moeten hebben geconfigureerd. Hierdoor kan je cluster OIDC-gebaseerde authenticatie gebruiken tegen Azure-resources. Workload identity stelt je in staat om Azure Active Directory (AD)-identiteiten te “mappen” naar Kubernetes-serviceaccounts. Deze mapping maakt het mogelijk dat Kubernetes-workloads Azure AD Identity gebruiken om toegang te krijgen tot Azure-resources.
Als je op zoek bent om je applicaties die op Kubernetes draaien te beveiligen, overweeg dan het gebruik van een tool zoals kube-bench om te controleren op veelvoorkomende beveiligingsproblemen. Je kunt ook meer lezen over het beveiligen van Kubernetes-clusters in het algemeen in de Kubernetes-documentatie.
Laat me weten wat je ervan vindt, ik hoor graag van je.