55 Semaphore Benutzer- und Rechtekonzept

55.1 Benutzerverwaltung

Semaphore unterstützt verschiedene Benutzerquellen und -verwaltungsmodelle, die je nach Organisationsanforderungen konfiguriert werden können.

55.1.1 Lokale Benutzerkonten

Erstellung durch Administrator:

Self-Registration:

Benutzereigenschaften:

55.1.2 LDAP/Active Directory Integration

Charakteristika:

Benutzer-Mapping:

LDAP-Attribut → Semaphore-Feld
sAMAccountName → Username
displayName → Full Name
mail → Email
memberOf → Team-Zugehörigkeit

Vorteile:

55.1.3 OAuth/OpenID Connect

Unterstützte Provider:

Benutzerverhalten:

Vorteile:

55.1.4 Passwort-Policies und Session-Management

55.1.4.1 Passwort-Anforderungen

Semaphore verwendet standardmäßig grundlegende Passwort-Anforderungen:

55.1.4.2 Session-Verwaltung

Kernparameter:

55.2 Rollen und Berechtigungen

55.2.1 Rollen-Übersicht

Semaphore verwendet ein rollenbasiertes Berechtigungssystem mit vier Hauptrollen:

Rolle Berechtigungen Einschränkungen Typische Einsatzbereiche
Admin Vollzugriff auf alle Systembereiche, Benutzerverwaltung, globale Konfiguration, System-Updates Keine Installation, Konfiguration, Benutzerverwaltung, System-Monitoring
Project Admin Vollzugriff auf zugewiesene Projekte, lokale Benutzerverwaltung, Template- und Inventory-Management Keine globalen Einstellungen, kein Zugriff auf andere Projekte Projekt-Konfiguration, Team-Management, Template-Verwaltung
Operator Ausführung vorkonfigurierter Templates, Einsicht in Job-Historie und Logs Keine Template-Modifikation, keine Credential-Verwaltung, keine Konfiguration Job-Ausführung, Deployment-Operations, Routine-Tasks
Viewer Einsicht in Projekt-Konfiguration, Job-Historie und Logs Keine Job-Ausführung, keine Konfigurationsänderungen, keine Credential-Einsicht Monitoring, Reporting, Audit-Einsicht, Status-Überwachung

55.2.2 Granulare Rechtezuweisung

55.2.2.1 Ressourcen-spezifische Berechtigungen

Template-Ebene:

Inventory-Ebene:

Repository-Ebene:

55.2.3 Praktische Berechtigungsbeispiele

55.2.3.1 Szenario 1: Entwickler-Team

Anforderung: Deployment-Zugriff nur für eigene Anwendung

Konfiguration:

Benutzer: developer1, developer2, developer3
Rolle: Operator
Projekt: webapp-deployment
Templates: deploy-webapp (Execute), rollback-webapp (Execute)
Inventories: webserver-staging, webserver-production (Use)
Credentials: Kein direkter Zugriff

55.2.3.2 Szenario 2: Infrastructure Team

Anforderung: Vollzugriff auf Infrastruktur-Projekte

Konfiguration:

Benutzer: infra-admin
Rolle: Project Admin
Projekte: infrastructure-management, monitoring-setup
Templates: Alle (Admin)
Inventories: Alle (Write)
Credentials: Alle im Projekt-Scope (Admin)

55.2.3.3 Szenario 3: Audit-Team

Anforderung: Nur-Lese-Zugriff für Compliance

Konfiguration:

Benutzer: auditor1
Rolle: Viewer
Projekte: Alle (Read-Only)
Job-Historie: Vollständige Einsicht
Credentials: Keine Einsicht in Secrets

55.2.4 Role-Based Access Control (RBAC)

55.2.4.1 RBAC-Prinzipien

Benutzer → Rolle → Berechtigung:

Benutzer: developer1
Rolle: Application-Operator
Berechtigungen:
├── Template-Execution: deploy-app, rollback-app
├── Inventory-Access: staging-servers, production-servers
└── Credential-Usage: app-deployment-key (keine Einsicht)

Prinzip der minimalen Berechtigung:

55.2.4.2 RBAC-Matrix

Rolle Templates Inventories Credentials Job-Historie
Viewer Read Read None Read
Operator Execute Use Use (no view) Read
Project Admin Admin Admin Admin Admin
Admin Admin (global) Admin (global) Admin (global) Admin (global)

55.3 Sicherheit

55.3.1 Verwaltung von SSH-Keys, Tokens und Passwörtern

55.3.1.1 Credential-Typen

SSH-Keys:

Username/Password:

Access-Tokens:

55.3.1.2 Credential-Erstellung und -Verwaltung

SSH-Key-Generierung:

# Key-Pair generieren
ssh-keygen -t rsa -b 4096 -C "semaphore-deployment" -f semaphore_key

# Public Key auf Zielsystemen installieren
ssh-copy-id -i semaphore_key.pub user@target-server

# Private Key in Semaphore importieren
# Web-Interface: Project → Key Store → Create Key

Credential-Metadaten:

Name: deployment-key-production
Type: SSH Key
Description: Production server access
Scope: Project-specific
Rotation: Every 90 days

55.3.2 Credential-Scopes

55.3.2.1 Global Credentials

Eigenschaften:

Anwendungsfall:

Global SSH-Key: infrastructure-master-key
Verwendung: Backup-Server, Monitoring-Systeme, Shared Services
Zugriff: Alle Infrastructure-Templates organisationsweit

55.3.2.2 Projekt-spezifische Credentials

Eigenschaften:

Anwendungsfall:

Projekt: E-Commerce-Platform
Credentials:
├── ecommerce-db-password (Database-Access)
├── payment-api-token (Payment-Provider)
└── deployment-key (Application-Servers)

55.4 Integration externer Secrets-Manager

55.4.1 HashiCorp Vault Integration

Vault-Konfiguration:

{
  "vault_enable": true,
  "vault_address": "https://vault.company.com",
  "vault_auth_method": "kubernetes",
  "vault_namespace": "semaphore",
  "vault_secret_engine": "kv-v2"
}

Vault-Policy für Semaphore:

path "secret/data/semaphore/*" {
  capabilities = ["read"]
}
path "auth/token/lookup-self" {
  capabilities = ["read"]
}

55.4.2 AWS Secrets Manager

AWS-Integration:

{
  "aws_secrets_enable": true,
  "aws_region": "eu-central-1",
  "aws_role_arn": "arn:aws:iam::account:role/SemaphoreSecretsRole"
}

Playbook-Integration:

- name: Get database credentials from AWS Secrets Manager
  set_fact:
    db_credentials: "{{ lookup('amazon.aws.aws_secret', 'prod/database/credentials') | from_json }}"
  no_log: true

55.4.3 Azure Key Vault

Azure Key Vault Lookup:

- name: Retrieve SSL certificate from Key Vault
  azure_rm_keyvaultsecret_info:
    vault_uri: "https://prod-secrets.vault.azure.net/"
    name: "ssl-certificate"
  register: ssl_cert
  no_log: true

55.5 Best Practices

55.5.1 Credential-Sicherheit

Verschlüsselung:

Zugriffskontrolle:

Credential: production-database-password
├── Encryption: AES-256-GCM
├── Access-Log: Alle Zugriffe protokolliert
├── Usage-Restriction: Nur durch autorisierte Templates
└── Rotation-Policy: 30 Tage

Sichere Praktiken:

55.5.2 Credential-Rotation

Automatische Rotation:

Rotation-Workflow:

1. Neues Credential generieren
2. Abhängige Systeme aktualisieren
3. Altes Credential deaktivieren
4. Funktionstest durchführen
5. Altes Credential löschen

Rotation-Schedule:

55.5.3 Audit und Compliance

Zugriffs-Logging:

Compliance-Reports:

Credential-Audit-Report:
├── Credential-Name: production-ssh-key
├── Last-Used: 2024-08-15 14:30:22
├── Used-By: user@example.com
├── Template: deploy-production
├── Result: Success
└── Next-Rotation: 2024-09-15

Compliance-Metriken: