TL;DR

Automatisiertes Onboarding erstellt Namespace, RBAC-Rollen, ResourceQuotas und Kubeconfig per Script oder Operator. Mit ArgoCD ApplicationSets bekommt jedes neue Team automatisch seine Umgebungen. Das reduziert Time-to-First-Deploy von Tagen auf Minuten und entlastet das Platform-Team.

Developer Onboarding auf Kubernetes automatisieren

Ein neuer Entwickler braucht Zugriff auf den Cluster. Ohne Automatisierung heißt das: Ticket erstellen, warten, Namespace manuell anlegen, RBAC konfigurieren, Kubeconfig verschicken. Drei Tage später kann die Person endlich arbeiten. Das geht besser.

Was gehört zum Onboarding?

Jeder neue Entwickler oder jedes neue Team braucht mindestens:

# Onboarding-Checkliste als Code
onboarding_steps:
  - namespace_creation      # Isolierte Umgebung
  - rbac_role_binding       # Berechtigungen
  - resource_quotas         # Limits gegen Ressourcen-Explosion
  - network_policies        # Netzwerk-Isolation
  - kubeconfig_generation   # Cluster-Zugang
  - argocd_project          # GitOps-Zugang
  - registry_access         # Pull-Secrets für Container-Images

Namespace-Provisioning-Script

Das folgende Bash-Script automatisiert die komplette Einrichtung. Es erstellt Namespace, RBAC, Quotas und generiert eine Kubeconfig — alles in einem Durchlauf:

#!/bin/bash
# provision-team.sh - Automatisches Team-Onboarding
set -euo pipefail

TEAM_NAME=$1
CLUSTER_API="https://kubernetes.default.svc"
QUOTA_CPU="4"
QUOTA_MEMORY="8Gi"
QUOTA_PODS="20"

if [[ -z "$TEAM_NAME" ]]; then
  echo "Usage: $0 <team-name>"
  exit 1
fi

NS="team-${TEAM_NAME}"

echo "==> Erstelle Namespace ${NS}"
kubectl create namespace "$NS" --dry-run=client -o yaml | \
  kubectl apply -f -

kubectl label namespace "$NS" \
  team="$TEAM_NAME" \
  managed-by=platform-team \
  --overwrite

echo "==> Erstelle ResourceQuota"
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ResourceQuota
metadata:
  name: default-quota
  namespace: ${NS}
spec:
  hard:
    requests.cpu: "${QUOTA_CPU}"
    requests.memory: "${QUOTA_MEMORY}"
    limits.cpu: "$((QUOTA_CPU * 2))"
    limits.memory: "$((${QUOTA_MEMORY%Gi} * 2))Gi"
    pods: "${QUOTA_PODS}"
    services: "10"
    persistentvolumeclaims: "5"
EOF

echo "==> Erstelle LimitRange"
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: ${NS}
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 100m
      memory: 128Mi
    type: Container
EOF

echo "==> Namespace ${NS} bereit"

RBAC-Rollen automatisch zuweisen

Erstelle eine ClusterRole mit den typischen Entwickler-Berechtigungen und binde sie pro Namespace:

# developer-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: developer
rules:
- apiGroups: ["", "apps", "batch"]
  resources: ["pods", "deployments", "services",
              "configmaps", "secrets", "jobs", "cronjobs"]
  verbs: ["get", "list", "watch", "create",
          "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["pods/log", "pods/exec", "pods/portforward"]
  verbs: ["get", "create"]
- apiGroups: ["networking.k8s.io"]
  resources: ["ingresses"]
  verbs: ["get", "list", "watch", "create", "update"]
---
# RoleBinding pro Team-Namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: team-frontend
subjects:
- kind: Group
  name: team-frontend
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: developer
  apiGroup: rbac.authorization.k8s.io

Das Provisioning-Script erstellt das RoleBinding automatisch:

# Ergänzung für provision-team.sh
echo "==> Erstelle RBAC RoleBinding"
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: ${NS}
subjects:
- kind: Group
  name: ${TEAM_NAME}
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: developer
  apiGroup: rbac.authorization.k8s.io
EOF

Kubeconfig generieren

Für Teams ohne SSO-Integration generierst du ServiceAccount-basierte Kubeconfigs:

# kubeconfig-generator.sh
SA_NAME="dev-${TEAM_NAME}"
kubectl create serviceaccount "$SA_NAME" -n "$NS"

# Token erstellen (Kubernetes 1.24+)
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: ${SA_NAME}-token
  namespace: ${NS}
  annotations:
    kubernetes.io/service-account.name: ${SA_NAME}
type: kubernetes.io/service-account-token
EOF

# Warten bis Token bereit ist
sleep 3
TOKEN=$(kubectl get secret "${SA_NAME}-token" -n "$NS" \
  -o jsonpath='{.data.token}' | base64 -d)

CA=$(kubectl get secret "${SA_NAME}-token" -n "$NS" \
  -o jsonpath='{.data.ca\.crt}')

# Kubeconfig schreiben
cat > "kubeconfig-${TEAM_NAME}.yaml" <<EOF
apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: ${CA}
    server: ${CLUSTER_API}
  name: production
contexts:
- context:
    cluster: production
    namespace: ${NS}
    user: ${SA_NAME}
  name: ${NS}
current-context: ${NS}
users:
- name: ${SA_NAME}
  user:
    token: ${TOKEN}
EOF

echo "==> Kubeconfig: kubeconfig-${TEAM_NAME}.yaml"

ArgoCD ApplicationSet für Team-Umgebungen

Statt jede ArgoCD-Application manuell anzulegen, nutze ein ApplicationSet. Sobald ein neuer Namespace mit dem Label team existiert, erstellt ArgoCD automatisch die Application:

# team-appset.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: team-environments
  namespace: argocd
spec:
  generators:
  - clusterDecisionResource:
      configMapRef: my-configmap
  - git:
      repoURL: https://git.example.com/platform/team-configs.git
      revision: HEAD
      directories:
      - path: "teams/*"
  template:
    metadata:
      name: '{{path.basename}}-app'
    spec:
      project: '{{path.basename}}'
      source:
        repoURL: https://git.example.com/platform/team-configs.git
        targetRevision: HEAD
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: 'team-{{path.basename}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
        - CreateNamespace=false

Die Git-Repo-Struktur dazu:

team-configs/
├── teams/
│   ├── frontend/
│   │   ├── kustomization.yaml
│   │   ├── namespace.yaml
│   │   └── network-policy.yaml
│   ├── backend/
│   │   ├── kustomization.yaml
│   │   ├── namespace.yaml
│   │   └── network-policy.yaml
│   └── data-engineering/
│       ├── kustomization.yaml
│       └── namespace.yaml

Neues Team onboarden = neuen Ordner im Git-Repo anlegen. ArgoCD erledigt den Rest.

Network Policy als Standard

Jeder neue Namespace bekommt eine Default-Network-Policy, die nur Traffic innerhalb des Namespaces erlaubt:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-external
  namespace: team-frontend
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: team-frontend
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx

Self-Service Portal

Für Teams ohne Kubernetes-Erfahrung ist ein Self-Service-Portal der nächste Schritt. Die Architektur:

Komponente	Aufgabe	Tool-Beispiel
Frontend	Formular für Team-Anfragen	Backstage, Port
API	Validierung, Provisioning auslösen	Custom Controller
GitOps	Gewünschten Zustand verwalten	ArgoCD, Flux
RBAC	Identität und Berechtigungen	Keycloak, Dex

Der Ablauf: Entwickler füllt Formular aus, API erstellt Pull Request im GitOps-Repo, Platform-Team reviewed, ArgoCD synct. Alles nachvollziehbar, alles auditierbar.

FAQ

Wie lange dauert automatisiertes Onboarding?

Mit dem Script: unter 2 Minuten. Mit Self-Service-Portal und Approval-Workflow: typischerweise unter einer Stunde. Ohne Automatisierung dauert es in den meisten Unternehmen 3-5 Werktage.

Sollte ich ServiceAccounts oder OIDC für Developer-Zugang nutzen?

OIDC über Keycloak oder Dex ist der bessere Weg. ServiceAccount-Tokens sind statisch und schwer zu rotieren. OIDC integriert sich in bestehendes Identity Management und erlaubt Token-Ablauf.

Wie verhindere ich, dass Teams ihre Quotas umgehen?

ResourceQuotas sind vom API-Server enforced — sie lassen sich nicht umgehen. Ergänze sie mit LimitRanges für Pod-Level-Defaults und einem Admission Webhook für Custom-Policies (z.B. Kyverno oder OPA Gatekeeper).

Was passiert beim Offboarding?

Das Offboarding-Script löscht Namespace, RoleBindings und ServiceAccounts. Wichtig: Vorher Daten sichern und laufende Workloads migrieren. Automatisiere auch das, sonst bleiben verwaiste Namespaces zurück.

Brauche ich einen Operator statt eines Scripts?

Für wenige Teams reicht das Script. Ab 10+ Teams lohnt sich ein Operator (z.B. mit Kubebuilder), der auf Custom Resources reagiert. So wird kubectl apply -f team-frontend.yaml zum einzigen Onboarding-Schritt.

Kubernetes-Expertise gesucht?

Managed Services, Beratung, Training oder Security – wir unterstützen deutsche Unternehmen bei allen Kubernetes-Themen.

Kontakt aufnehmen Kontakt aufnehmen

Developer Onboarding auf Kubernetes automatisieren

TL;DR

Developer Onboarding auf Kubernetes automatisieren

Was gehört zum Onboarding?

Namespace-Provisioning-Script

RBAC-Rollen automatisch zuweisen

Kubeconfig generieren

ArgoCD ApplicationSet für Team-Umgebungen

Network Policy als Standard

Self-Service Portal

FAQ

Wie lange dauert automatisiertes Onboarding?

Sollte ich ServiceAccounts oder OIDC für Developer-Zugang nutzen?

Wie verhindere ich, dass Teams ihre Quotas umgehen?

Was passiert beim Offboarding?

Brauche ich einen Operator statt eines Scripts?

Kubernetes-Expertise gesucht?

Kubernetes-Beratung gesucht?

📖 Verwandte Artikel

Backstage Developer Portal auf Kubernetes einrichten

Kubernetes Self-Service Portal mit Backstage und Crossplane

Platform Engineering: Self-Service auf Kubernetes

Kubernetes Platform Team aufbauen: IDP Anleitung

Die Top Kubernetes Twitter Accounts zum Folgen: X Feeds für DevOps & Platform Engineers