Access & Observability¶
kubeconfig-Lifecycle, erlaubte Clients, Managed Grafana vs. eigener Stack. IAM/OIDC/RBAC: Access Control. Komponenten: Grafana, VictoriaMetrics. Logs anliefern (K8s, Syslog, Host-Collector): Logs ingestieren.
kubeconfig — Lifecycle¶
| Phase | Was passiert |
|---|---|
| Ausstellung | ayedo / Identity-Flow liefert eine kubeconfig (Datei oder Download). Bei OIDC oft mit kubelogin/Exec-Plugin statt langlebigem Client-Zertifikat. |
| Gültigkeit | Session-/Token-Laufzeit folgt IdP und Cluster-Konfiguration. Abgelaufene Tokens erfordern erneuten Login — die Datei bleibt, Credentials nicht. |
| Rotation | Nach Rollenwechsel, Verdacht auf Leak oder periodischer Policy: neue Credentials ausstellen, alte widerrufen. |
| Revocation | IdP-User deaktivieren / Gruppe entfernen / Client-Zertifikat sperren; bei Zertifikats-kubeconfigs Datei als kompromittiert behandeln und ersetzen. |
Empfehlungen:
- kubeconfig nicht in Git oder Chat teilen
- Pro Person/Service Account getrennte Identitäten
- Break-Glass-Admin nur offline und auditiert
Technische OIDC-kubeconfig-Beispiele: Access Control — kubelogin.
Erlaubte Clients¶
| Client | Status |
|---|---|
| kubectl | unterstützt (CLI-Standard) |
| Lens / vergleichbare Desktop-IDEs | erlaubt, sofern sie die bereitgestellte kubeconfig/OIDC nutzen |
| CI/CD (GitHub Actions, GitLab CI, …) | über kurze Tokens / Workload Identity / Service Accounts — nicht über persönliche Langzeit-kubeconfigs |
| Upstream Kubernetes Dashboard | kein verpflichtender Plattform-Standard; optional nur wenn explizit deployed und freigegeben |
Zugriff bleibt an RBAC und ggf. Control-Plane-IP-Whitelist gebunden — siehe Network Access.
Platform Grafana¶
Metriken und Logs der Plattform liegen in VictoriaMetrics und VictoriaLogs. Die Oberfläche für Enduser ist Platform Grafana — eine Grafana-Organisation pro Polycrate-Organisation, reconciliert von der Polycrate API.
Die API ist Source of Truth (Membership, Rollen, Datasources, Dashboard-Subscriptions). Grafana selbst ist downstream. Architektur: polycrate-api Topic grafana-platform-integration.
Zugang¶
- User ist Member der Organisation in der Polycrate API (SSO/Keycloak).
- Reconciliation legt den Grafana-User in der Org an und setzt die Rolle.
- Login: Platform-Grafana-URL der Installation (OIDC, derselbe IdP wie die API).
- Nach dem Login: Org-Kontext der eigenen Organisation; Datasources VM (
victoriametrics) und VL (victorialogs).
IAM-Details und Gruppen-Mapping: Access Control — Grafana.
Es gibt zusätzlich ein Operations Grafana (Catalog-Quelle, Plattform-Betrieb). Enduser arbeiten in Platform Grafana.
Was Sie sehen¶
| Quelle | Inhalt |
|---|---|
| Catalog-Dashboards | Von Operations Grafana importiert (Tag polycrate-sync); Default-Dashboards auto-subscribe |
| Cluster / Nodes / Workloads | Kubernetes-Status, Kapazität — siehe Kapazitätsplanung |
| App-Metriken | eigene /metrics + VMServiceScrape / VMPodScrape (Best Practices) |
| Logs | Explore → Datasource VL, LogsQL; CLI: polycrate logs (Observability CLI) |
| Metriken ad hoc | Explore → VM (MetricsQL); CLI: polycrate metrics |
Datasource-UIDs nicht umbenennen — die API erwartet victoriametrics / victorialogs.
Day-2¶
- Eigene Dashboards in der Org anlegen; globale Datasources und Alertmanager sind Plattform-Scope.
- Alert-Routing für Apps: User Alerts.
- kubeconfig bleibt der Weg zu
kubectl; Grafana ersetzt das Cluster-API nicht.
Stack (Blöcke)¶
Die SDP stellt typischerweise bereit:
- VictoriaMetrics — ayedo/k8s/victoria-metrics-stack
- VictoriaLogs — ayedo/k8s/victoria-logs — Ingest: Logs ingestieren
- Grafana — Platform-Instanz, angebunden über die API
Kunden nutzen Platform Grafana. Eigene Dashboards im Org-Ordner sind üblich.
Kundeneigene Monitoring-Stacks¶
Erlaubt im Tenant-Namespace (Prometheus Agent, OpenTelemetry Collector, eigenes Grafana u. ä.), mit Klarstellungen:
| Thema | Erwartung |
|---|---|
| Scraping | nur eigene Workloads/Namespaces; keine Plattform-Control-Plane ohne Freigabe |
| Egress | externe SaaS-Backends ggf. stabile Egress-IPs brauchen — Network Access |
| Alerting | Kunden-PagerDuty/Slack etc. in Kundenverantwortung; Plattform-Alerts bleiben ayedo-betrieben |
| Doppelte Last | parallele Full-Cluster-Scrape-Stacks mit Support abstimmen |
Shared Responsibility¶
| ayedo | Kunde |
|---|---|
| IdP-/Cluster-Zugangspfad, RBAC-Grundlagen | sichere Aufbewahrung der kubeconfig, MFA am IdP |
| Managed Metrics/Logs/Grafana im Scope | App-Metriken, Business-Alerts, eigene Stacks |
| Plattform-Incidents | App-Incidents und Runbooks im Tenant |