Ausführung von AWX auf Kubernetes mit HashiCorp Vault Secrets Injector: Eine nahtlose Integration für sichere Automatisierung

In der sich ständig weiterentwickelnden Welt der IT-Automatisierung dient AWX als leistungsstarkes webbasiertes Benutzerinterface für Ansible, das komplexe und repetitive Aufgaben innerhalb Ihrer Kubernetes-Umgebung vereinfacht. Um die Sicherheit zu erhöhen und den Bereitstellungsprozess zu optimieren, bietet die Kombination von AWX mit dem Secrets Injector von HashiCorp Vault eine robuste Lösung zur Verwaltung sensibler Daten und Geheimnisse.

In diesem Beitrag werden wir untersuchen, wie AWX auf Kubernetes bereitgestellt werden kann und wie Sie Ihre Geheimnisse mithilfe von HashiCorp Vault sicher verwalten. Außerdem gehen wir auf die Verwendung von Instanzgruppen in AWX für maßgeschneiderte Ausführungsumgebungen ein, die die Flexibilität und Effizienz bei der Ausführung von Ansible-Playbooks in Kombination mit HashiCorp Vault erhöhen.

Voraussetzungen

Bevor wir beginnen, stellen Sie sicher, dass Sie Folgendes haben:

• Ein Kubernetes-Cluster (Minikube oder eine andere Distribution).
• kubectl und helm auf Ihrem lokalen Rechner installiert.
• Den AWX Operator zur Verwaltung von AWX-Bereitstellungen.
• Eine Instanz von HashiCorp Vault, die mit der Kubernetes Secrets Engine konfiguriert ist.
• Administratorzugriff auf Ihren Kubernetes-Cluster.

Bereitstellen von AWX auf Kubernetes

Installation des AWX Operators

Der AWX Operator vereinfacht die Bereitstellung und Verwaltung von AWX auf Kubernetes. Installieren Sie es zuerst mit Kustomize:

1---
2apiVersion: kustomize.config.k8s.io/v1beta1
3kind: Kustomization
4namespace: awx
5resources:
6  - github.com/ansible/awx-operator/config/default?ref=2.19.1

AWX bereitstellen

Erstellen Sie eine benutzerdefinierte Ressourcendefinition (CRD) zur Bereitstellung von AWX:

 1apiVersion: awx.ansible.com/v1beta1
 2kind: AWX
 3metadata:
 4    name: awx
 5    namespace: awx
 6spec:
 7    service_type: ClusterIP
 8    ingress_type: ingress
 9    ingress_hosts:
10    - hostname: awx.example.com
11    postgres_storage_size: 8Gi  # Passen Sie die Speichergröße nach Bedarf an
12create_preload_data: false

Konfiguration anwenden:

1kubectl apply -f awx-deployment.yaml

Integration des HashiCorp Vault Secrets Injector

Der Secrets Injector von Vault ist ein Kubernetes Mutating Admission Webhook, um Geheimnisse direkt in Anwendungspods einzubinden.

Den Secrets Injector aktivieren

Den Vault Agent Injector mit Helm bereitstellen:

1helm repo add hashicorp https://helm.releases.hashicorp.com
2helm install vault hashicorp/vault \
3    --set "global.externalVaultAddr=https://vault.example.com:8200" \
4    --set "server.enabled=false" \
5    --set "injector.enabled=true" \
6    --set "injector.authPath=auth/kubernetes"

Vault-Richtlinien und Rollen konfigurieren

Definieren Sie eine Richtlinie in Vault, um den Zugriff auf Geheimnisse zu ermöglichen:

1path "secret/data/*" {
2    capabilities = ["read"]
3}

1vault policy write awx-access ./awx-access.hcl

Aktivieren Sie die Kubernetes-Authentifizierungsmethode und binden Sie eine Rolle an diese:

1vault auth enable kubernetes
2vault write auth/kubernetes/role/awx \
3    bound_service_account_names=awx-execution \
4    bound_service_account_namespaces=awx \
5    policies=default,awx-access \
6    ttl=1h

Überprüfung der Injection von Geheimnissen in Pods

1apiVersion: v1
2kind: ServiceAccount
3metadata:
4  name: awx-execution
5  namespace: awx

Annotieren Sie Ihre Testpods, um sicherzustellen, dass der Vault Injector die benötigten Geheimnisse injiziert:

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4    name: awx-pod
 5    namespace: awx
 6    annotations:
 7        vault.hashicorp.com/agent-inject: "true"
 8        vault.hashicorp.com/role: "awx"
 9        vault.hashicorp.com/agent-inject-secret-database: "secret/data/mysql"
10spec:
11    serviceAccountName: awx-execution
12    automountServiceAccountToken: true
13    ...

Anpassung der AWX-Ausführung mit Instanzgruppen

AWX Instanzgruppen ermöglichen es Ihnen, Umgebungen anhand benutzerdefinierter Kriterien zu trennen. Instanzgruppen in AWX können definiert werden, um Aufgaben basierend auf spezifischen Ressourcenbedürfnissen oder Arbeitslasten zuzuweisen. Wir werden diese Funktion nutzen, um unseren Ausführungspod mit einigen Anmerkungen für Vault-Injektionen zu verbessern.

 1terraform {
 2  required_providers {
 3    awx = {
 4      source = "ilijamt/awx"
 5    }
 6  }
 7}
 8variable "awx_user" {
 9  type    = string
10  default = "admin"
11}
12variable "awx_password" {
13  type      = string
14  ephemeral = true
15  sensitive = true
16}
17provider "awx" {
18  hostname = "https://awx.examples.com"
19  username = var.awx_user
20  password = var.awx_password
21}
22resource "awx_instance_group" "vault_enabled_instances" {
23    name = "vault-enabled"
24    is_container_group = true
25    pod_spec_override = <<EOT
26apiVersion: v1
27kind: Pod
28metadata:
29  namespace: awx
30  annotations:
31    "vault.hashicorp.com/agent-inject": "true"
32    "vault.hashicorp.com/role": "awx"
33    "vault-hashicorp-com-agent-inject-token": "true"
34    "vault.hashicorp.com/agent-inject-secret-token.sh: |
35        {{- with secret "auth/token/lookup-self" -}}
36            export VAULT_TOKEN="{{ .Data.id }}"
37        {{- end }}
38spec:
39  serviceAccountName: awx-operator
40  automountServiceAccountToken: true
41  containers:
42    - image: quay.io/ansible/awx-ee:latest
43      name: worker
44      command: [ "source /vault/secrets/token.sh && /bin/bash -c" ]
45      args:
46        - ansible-runner
47        - worker
48        - '--private-data-dir=/runner'
49      resources:
50        requests:
51          cpu: 250m
52          memory: 100Mi
53EOT
54}

Zuordnen von Playbooks zu Instanzgruppen

Beim Konfigurieren einer Jobvorlage in AWX weisen Sie sie der neu erstellten Instanzgruppe zu, um sicherzustellen, dass Playbooks in einer maßgeschneiderten Umgebung ausgeführt werden. Alle Playbooks haben ein gültiges Vault-Token, um mit Vault zu interagieren, um auf die Daten gemäß der erstellten Richtlinie zuzugreifen. Eine flexiblere Möglichkeit wäre, ein Token an den Pod-Container zu übergeben, das es den Playbooks ermöglicht, sich gegen AppRole-Rollen zu authentifizieren. Gemäß der tatsächlichen Rollenkonfiguration können unterschiedliche Berechtigungen gewährt werden. Alternativ können Sie mehrere Instanzgruppen erstellen, die sich auf Kubernetes-Rollen beziehen, die unterschiedliche Berechtigungen für die Vault-Ressourcen definieren.

Fazit

Die Kombination von AWX mit HashiCorp Vault auf Kubernetes verbessert die Automatisierungsmöglichkeiten Ihrer Infrastruktur, während hohe Sicherheitsstandards für sensible Daten gewahrt werden. Dank der Nutzung von AWX-Instanzgruppen können Sie hochgradig anpassbare und effiziente Umgebungen schaffen, die auf Ihre spezifischen Automatisierungsbedürfnisse zugeschnitten sind. Diese Integration stärkt Ihre DevOps-Praktiken, indem sie sowohl Agilität als auch Sicherheit in Ihren organisatorischen Arbeitsabläufen fördert.

Beginnen Sie noch heute damit, Ihre robusten Automatisierungslösungen mit AWX und HashiCorp Vault zu entwickeln!