Jeder Entwickler hat diese Versuchung schon erlebt: Sie müssen schnell etwas testen, also codieren Sie einen API-Schlüssel oder ein Datenbankpasswort direkt in Ihren Code oder Ihre Konfigurationsdatei. "Ich werde es vor dem Commit entfernen", sagen Sie sich selbst. Aber wir alle wissen, wie diese Geschichte endet - Zugangsdaten landen in Repositories, werden in Slack-Kanälen geteilt oder enden in Produktionskonfigurationsdateien.
Die Konsequenzen sind real. Datenlecks, kompromittierte Systeme und Sicherheitsvorfälle lassen sich oft auf offengelegte Zugangsdaten zurückführen. Die Lösung besteht nicht nur darin, "vorsichtiger zu sein" - wir benötigen geeignete Tools und Workflows, die es einfacher machen, das Richtige zu tun als das Falsche.
In diesem Leitfaden werden wir zwei komplementäre Ansätze für das Credential-Management erkunden:
Beide Tools sind hervorragend darin, Zugangsdaten aus Ihrem Code und Konfigurationsdateien fernzuhalten, aber sie dienen unterschiedlichen Anwendungsfällen und können wunderbar zusammenarbeiten.
Während die meisten Menschen 1Password als Browser-Erweiterung zum Speichern von Passwörtern kennen, bringt die 1Password CLI Secrets Management direkt in Ihren Entwicklungs-Workflow.
1# Anmelden
2op signin
3
4# Tresore auflisten
5op vault list
6
7# Elemente in einem Tresor auflisten
8op item list --vault "Development"
9
10# Ein bestimmtes Element abrufen
11op item get "GitHub Token" --vault "Development"
12
13# Nur ein bestimmtes Feld abrufen
14op item get "GitHub Token" --fields password
op runDie eigentliche Magie passiert mit op run, das es ermöglicht, Secrets als Umgebungsvariablen zu injizieren, ohne sie jemals in Ihrer Shell-Historie oder Prozessliste offenzulegen.
Erstellen Sie zunächst eine .env-Datei mit Verweisen auf 1Password-Elemente:
1# .env
2DB_PASSWORD="op://Development/PostgreSQL/password"
3API_KEY="op://Development/Stripe API/credential"
4AWS_ACCESS_KEY_ID="op://Development/AWS/access_key_id"
5AWS_SECRET_ACCESS_KEY="op://Development/AWS/secret_access_key"
6GITHUB_TOKEN="op://Development/GitHub/token"
Die Syntax ist: op://<tresor>/<element>/<feld>
Führen Sie jetzt Ihre Anwendung mit injizierten Secrets aus:
1# Node.js-Anwendung ausführen
2op run -- node app.js
3
4# Python-Skript ausführen
5op run -- python manage.py runserver
6
7# Docker Compose ausführen
8op run -- docker-compose up
9
10# Terraform ausführen
11op run -- terraform apply
12
13# Jeden Befehl mit injizierten Secrets ausführen
14op run -- ./ihre-anwendung
Schauen wir uns reale Szenarien an, bei denen die 1Password CLI Ihren Entwicklungs-Workflow von unsicher zu sicher transformieren kann.
Betrachten Sie eine typische Node.js-Anwendung, die eine Verbindung zu einer Datenbank herstellen muss. Der unsichere Ansatz, in den viele Entwickler verfallen, sieht in Ihrer config.js so aus:
1// Niemals so machen
2module.exports = {
3 database: {
4 host: 'localhost',
5 user: 'admin',
6 password: 'SuperSecret123!', // Fest codiert!
7 database: 'myapp'
8 }
9};
Dies ist gefährlich, weil das Passwort direkt in Ihrem Quellcode steht, für jeden mit Repository-Zugriff sichtbar ist und wahrscheinlich in der Versionskontroll-Historie landen wird, selbst wenn Sie versuchen, es später zu entfernen.
Refaktorieren Sie stattdessen Ihre Konfiguration, um aus Umgebungsvariablen zu lesen:
1// Aus Umgebungsvariablen lesen
2module.exports = {
3 database: {
4 host: process.env.DB_HOST || 'localhost',
5 user: process.env.DB_USER || 'admin',
6 password: process.env.DB_PASSWORD, // Injiziert durch op run
7 database: process.env.DB_NAME || 'myapp'
8 }
9};
Jetzt enthält Ihr Code keine Secrets - er verweist nur auf Umgebungsvariablen. Die Fallback-Werte (mit ||) bieten Standardwerte für nicht-sensitive Einstellungen, aber beachten Sie, dass DB_PASSWORD keinen Fallback hat, wodurch sichergestellt wird, dass die Anwendung schnell fehlschlägt, wenn das Secret nicht bereitgestellt wird.
Als nächstes erstellen Sie eine .env-Datei im Stammverzeichnis Ihres Projekts mit 1Password-Secret-Referenzen. Diese Datei kann sicher in die Versionskontrolle eingecheckt werden, weil sie keine tatsächlichen Secrets enthält, nur Verweise auf Elemente in Ihrem 1Password-Tresor:
1DB_HOST=localhost
2DB_USER=admin
3DB_PASSWORD=op://Development/PostgreSQL/password
4DB_NAME=myapp
Die Magie liegt in der op://-Referenz-Syntax. Wenn Sie Ihre Anwendung durch op run ausführen, löst die 1Password CLI diese Referenzen automatisch auf, holt das tatsächliche Passwort aus Ihrem Tresor und injiziert es als Umgebungsvariable - aber nur für die Dauer des Prozesses Ihrer Anwendung.
Führen Sie schließlich Ihre Anwendung aus:
1op run -- node app.js
Das ---Trennzeichen teilt op run mit, dass alles danach der auszuführende Befehl ist. Ihre Anwendung läuft normal, aber mit sicher injizierten Secrets, die niemals Ihr Dateisystem berühren oder in Prozesslisten erscheinen.
Über die lokale Entwicklung hinaus lässt sich 1Password nahtlos in CI/CD-Pipelines integrieren. So injizieren Sie Secrets in GitHub Actions sicher, ohne sie in Ihren Workflow-Dateien oder Logs offenzulegen:
1name: Deploy
2on: [push]
3
4jobs:
5 deploy:
6 runs-on: ubuntu-latest
7 steps:
8 - uses: actions/checkout@v3
9
10 - name: Secrets aus 1Password laden
11 uses: 1password/load-secrets-action@v1
12 with:
13 export-env: true
14 env:
15 OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
16 AWS_ACCESS_KEY_ID: op://Production/AWS/access_key_id
17 AWS_SECRET_ACCESS_KEY: op://Production/AWS/secret_access_key
18
19 - name: Auf AWS deployen
20 run: |
21 # Secrets sind jetzt als Umgebungsvariablen verfügbar
22 aws s3 sync ./dist s3://my-bucket
Das OP_SERVICE_ACCOUNT_TOKEN wird als GitHub-Secret gespeichert (das einzige Secret, das Sie dort speichern müssen!), und die Action verwendet es, um alle anderen Secrets aus 1Password abzurufen. Dieser Ansatz zentralisiert das Secret-Management in 1Password und hält Ihre CI/CD-Workflows sauber und nachprüfbar.
Wenn Sie mehr programmatische Kontrolle über das Abrufen von Secrets benötigen, bietet 1Password offizielle SDKs für Go, JavaScript und Python. Diese SDKs sind perfekt für Anwendungen, die Secrets dynamisch zur Laufzeit abrufen müssen, anstatt sich auf die Injektion von Umgebungsvariablen zu verlassen:
1import asyncio
2import os
3from onepassword import Client
4
5async def main():
6 # Initialize client with service account token
7 client = await Client.authenticate(
8 auth=os.environ.get("OP_SERVICE_ACCOUNT_TOKEN"),
9 integration_name="My App",
10 integration_version="v1.0.0"
11 )
12
13 # Resolve a secret reference
14 password = await client.secrets.resolve("op://Development/Database/password")
15
16 # Use it in your application
17 db_connection = await connect_to_database(
18 host="localhost",
19 user="admin",
20 password=password,
21 database="myapp"
22 )
23
24if __name__ == '__main__':
25 asyncio.run(main())
Der SDK-Ansatz gibt Ihnen feinkörnige Kontrolle darüber, wann und wie Secrets abgerufen werden. Er ist besonders nützlich für lang laufende Anwendungen wie Webserver, die möglicherweise Secrets periodisch aktualisieren müssen, oder für Anwendungen, die verschiedene Secrets basierend auf Laufzeitbedingungen abrufen müssen.
1// JavaScript/Node.js-Beispiel mit 1Password SDK
2import { createClient } from "@1password/sdk";
3
4// Client initialisieren (benötigt OP_SERVICE_ACCOUNT_TOKEN Umgebungsvariable)
5const client = await createClient({
6 auth: process.env.OP_SERVICE_ACCOUNT_TOKEN,
7 integrationName: "My App",
8 integrationVersion: "v1.0.0",
9});
10
11// Secret-Referenz auflösen
12const password = await client.secrets.resolve("op://Development/Database/password");
13
14// In Ihrer Anwendung verwenden
15const connection = await connectToDatabase({
16 host: "localhost",
17 user: "admin",
18 password: password,
19 database: "myapp"
20});
Während 1Password hervorragend für Entwickler-Workflows und kleinere Teams ist, wurde HashiCorp Vault für Enterprise-Secrets-Management mit erweiterten Funktionen wie dynamischen Secrets, Verschlüsselung als Service und umfassender Audit-Protokollierung entwickelt.
Beginnen wir mit grundlegenden Vault-Operationen. Für lokale Experimente können Sie einen Entwicklungsserver ausführen (Hinweis: Verwenden Sie niemals den Dev-Modus in der Produktion, da er Daten im Speicher speichert und unversiegelt läuft):
1# Dev-Server starten (nur zum Testen!)
2vault server -dev
3
4# In einem anderen Terminal die Adresse setzen
5export VAULT_ADDR='http://127.0.0.1:8200'
6
7# Authentifizieren
8vault login <root-token>
9
10# Ein Secret schreiben (KV v2)
11vault kv put -mount=secret myapp/config \
12 db_password="SuperSecret123" \
13 api_key="sk_test_123456"
14
15# Ein Secret lesen
16vault kv get -mount=secret myapp/config
17
18# Nur ein Feld abrufen
19vault kv get -mount=secret -field=db_password myapp/config
Die Key-Value (KV) Secrets Engine ist Vaults einfachstes Speicher-Backend, perfekt für statische Secrets wie API-Schlüssel und Passwörter. Das Flag -mount=secret gibt an, welcher KV-Mount verwendet werden soll - secret ist der Standard im Dev-Modus.
Es gibt mehrere Strategien, um Secrets aus Vault in Ihre Anwendungen zu bringen. Jede hat unterschiedliche Kompromisse in Bezug auf Komplexität, Sicherheit und operativen Aufwand.
vault kvDer einfachste Ansatz ist, ein Wrapper-Skript zu schreiben, das Secrets aus Vault abruft und sie als Umgebungsvariablen exportiert, bevor Ihre Anwendung gestartet wird:
1#!/bin/bash
2# load-secrets.sh
3
4export DB_PASSWORD=$(vault kv get -mount=secret -field=db_password myapp/config)
5export API_KEY=$(vault kv get -mount=secret -field=api_key myapp/config)
6export AWS_ACCESS_KEY_ID=$(vault kv get -mount=secret -field=access_key_id aws/credentials)
7export AWS_SECRET_ACCESS_KEY=$(vault kv get -mount=secret -field=secret_access_key aws/credentials)
8
9# Ihre Anwendung ausführen
10exec "$@"
Verwenden Sie es:
1./load-secrets.sh node app.js
2./load-secrets.sh python manage.py runserver
Dieser Ansatz ist unkompliziert, hat aber eine Einschränkung: Die Secrets werden in der Prozessumgebung offengelegt, die für andere Prozesse auf dem System sichtbar sein kann. Er funktioniert gut für Entwicklung und Tests, erfüllt aber möglicherweise nicht die Sicherheitsanforderungen für Produktionssysteme.
Für anspruchsvollere Deployments fungiert der Vault Agent als lokaler Daemon, der die Authentifizierung verwaltet und automatisch Konfigurationsdateien mit injizierten Secrets rendern kann. Dies ist besonders nützlich für Anwendungen, die Konfigurationsdateien anstelle von Umgebungsvariablen benötigen:
1# vault-agent-config.hcl
2pid_file = "./pidfile"
3
4vault {
5 address = "http://127.0.0.1:8200"
6}
7
8auto_auth {
9 method {
10 type = "approle"
11
12 config = {
13 role_id_file_path = "/etc/vault/role-id"
14 secret_id_file_path = "/etc/vault/secret-id"
15 }
16 }
17}
18
19template {
20 source = "/etc/app/config.tmpl"
21 destination = "/etc/app/config.json"
22}
Template-Datei (config.tmpl):
1{
2 "database": {
3 "host": "{{ with secret "secret/myapp/config" }}{{ .Data.data.db_host }}{{ end }}",
4 "password": "{{ with secret "secret/myapp/config" }}{{ .Data.data.db_password }}{{ end }}"
5 },
6 "api": {
7 "key": "{{ with secret "secret/myapp/config" }}{{ .Data.data.api_key }}{{ end }}"
8 }
9}
Starten Sie den Vault Agent, der sich mit AppRole authentifiziert und kontinuierlich auf Änderungen überwacht, wobei das Template bei jeder Aktualisierung der Secrets neu gerendert wird:
1vault agent -config=vault-agent-config.hcl
Der Vault Agent ist ideal für containerisierte Umgebungen und Systeme, bei denen Sie das Abrufen von Secrets vom Anwendungscode entkoppeln möchten. Der Agent übernimmt automatisch die Token-Erneuerung und stellt sicher, dass Ihre Anwendung immer gültige Credentials hat.
Für maximale Flexibilität und Kontrolle können Sie Vault direkt in Ihren Anwendungscode mithilfe offizieller SDKs integrieren.
1# Python-Beispiel mit AppRole-Authentifizierung
2import hvac
3import os
4
5# Vault-Client initialisieren
6client = hvac.Client(url='http://127.0.0.1:8200')
7
8# Mit AppRole authentifizieren
9auth_response = client.auth.approle.login(
10 role_id=os.environ.get('VAULT_ROLE_ID'),
11 secret_id=os.environ.get('VAULT_SECRET_ID')
12)
13
14# Ein Secret lesen
15secret = client.secrets.kv.v2.read_secret_version(
16 path='myapp/config'
17)
18
19db_password = secret['data']['data']['db_password']
20api_key = secret['data']['data']['api_key']
21
22# Die Secrets verwenden
23connection = connect_to_database(password=db_password)
1// Node.js-Beispiel mit AppRole-Authentifizierung
2import vault from 'node-vault';
3
4async function getSecrets() {
5 // Vault-Client initialisieren
6 const client = vault({
7 endpoint: 'http://127.0.0.1:8200'
8 });
9
10 // Mit AppRole authentifizieren
11 const authResponse = await client.approleLogin({
12 role_id: process.env.VAULT_ROLE_ID,
13 secret_id: process.env.VAULT_SECRET_ID
14 });
15
16 // Token wird automatisch von node-vault nach approleLogin gesetzt
17
18 // Secrets lesen
19 const result = await client.read('secret/data/myapp/config');
20
21 return {
22 dbPassword: result.data.data.db_password,
23 apiKey: result.data.data.api_key
24 };
25}
1// Go-Beispiel mit AppRole-Authentifizierung
2package main
3
4import (
5 "fmt"
6 "os"
7
8 vault "github.com/hashicorp/vault/api"
9)
10
11func main() {
12 // Vault-Client initialisieren
13 config := vault.DefaultConfig()
14 client, err := vault.NewClient(config)
15 if err != nil {
16 panic(err)
17 }
18
19 // Mit AppRole authentifizieren
20 authData := map[string]interface{}{
21 "role_id": os.Getenv("VAULT_ROLE_ID"),
22 "secret_id": os.Getenv("VAULT_SECRET_ID"),
23 }
24
25 authResponse, err := client.Logical().Write("auth/approle/login", authData)
26 if err != nil {
27 panic(err)
28 }
29
30 client.SetToken(authResponse.Auth.ClientToken)
31
32 // Secrets lesen
33 secret, err := client.Logical().Read("secret/data/myapp/config")
34 if err != nil {
35 panic(err)
36 }
37
38 data := secret.Data["data"].(map[string]interface{})
39 dbPassword := data["db_password"].(string)
40 apiKey := data["api_key"].(string)
41
42 fmt.Printf("DB Password: %s\n", dbPassword)
43 fmt.Printf("API Key: %s\n", apiKey)
44}
Eine der mächtigsten Funktionen von Vault sind dynamische Secrets - Zugangsdaten, die on-demand generiert werden und automatisch ablaufen. Im Gegensatz zu statischen Secrets, die Sie manuell speichern und rotieren, werden dynamische Secrets bei Anforderung erstellt und nach Ablauf ihrer Lease automatisch gelöscht. Dies reduziert die Angriffsfläche dramatisch: Wenn Credentials kompromittiert werden, sind sie nur für eine begrenzte Zeit gültig.
Lassen Sie uns Vault konfigurieren, um temporäre PostgreSQL-Zugangsdaten on-demand zu generieren. Aktivieren Sie zunächst die Database Secrets Engine und konfigurieren Sie sie für die Verbindung zu Ihrer Datenbank:
1# Database Secrets Engine aktivieren
2vault secrets enable database
3
4# PostgreSQL-Verbindung konfigurieren
5vault write database/config/mydb \
6 plugin_name=postgresql-database-plugin \
7 allowed_roles="readonly,readwrite" \
8 connection_url="postgresql://{{username}}:{{password}}@localhost:5432/myapp" \
9 username="vault" \
10 password="vault-password"
11
12# Rolle erstellen, die 1-Stunden-Zugangsdaten generiert
13vault write database/roles/readwrite \
14 db_name=mydb \
15 creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}' INHERIT; \
16 GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
17 default_ttl="1h" \
18 max_ttl="24h"
19
20# Zugangsdaten generieren (sie laufen automatisch ab!)
21vault read database/creds/readwrite
Jedes Mal, wenn Sie diesen Befehl ausführen, generiert Vault einen eindeutigen Benutzernamen und ein Passwort, erstellt eine PostgreSQL-Rolle mit diesen Zugangsdaten und gibt sie an Sie zurück. Die Ausgabe sieht so aus:
Key Value
--- -----
lease_id database/creds/readwrite/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h
lease_renewable true
password A1a-kR0dZ7y2wP3lR6qS
username v-token-readwrite-x4kt9txzx
Nach einer Stunde (der lease_duration) widerruft Vault diese Zugangsdaten automatisch. Ihre Anwendung kann die Lease vor Ablauf erneuern oder einfach neue Zugangsdaten anfordern - keine manuelle Rotation erforderlich.
Dynamische Secrets sind nicht auf Datenbanken beschränkt. So konfigurieren Sie Vault, um temporäre AWS-Zugangsdaten mit spezifischen Berechtigungen zu generieren:
1# AWS Secrets Engine aktivieren
2vault secrets enable aws
3
4# AWS-Zugangsdaten konfigurieren
5vault write aws/config/root \
6 access_key=AKIAIOSFODNN7EXAMPLE \
7 secret_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
8 region=us-east-1
9
10# Rolle erstellen, die temporäre AWS-Zugangsdaten generiert
11vault write aws/roles/ec2-admin \
12 credential_type=iam_user \
13 policy_document=-<<EOF
14{
15 "Version": "2012-10-17",
16 "Statement": [
17 {
18 "Effect": "Allow",
19 "Action": "ec2:*",
20 "Resource": "*"
21 }
22 ]
23}
24EOF
25
26# Temporäre AWS-Zugangsdaten generieren
27vault read aws/creds/ec2-admin
Dies erstellt einen echten IAM-Benutzer in AWS mit den angegebenen Berechtigungen, gibt die Zugangsdaten an Ihre Anwendung zurück und löscht den Benutzer automatisch, wenn die Lease abläuft. Dies ist unglaublich leistungsstark für CI/CD-Pipelines und temporäre Zugriffsszenarien - keine langlebigen AWS-Access-Keys mehr in Konfigurationsdateien.
Nachdem wir die technische Implementierung behandelt haben, lassen Sie uns operationelle Best Practices besprechen, die Ihnen helfen, ein sicheres Credential-Management-System langfristig aufrechtzuerhalten.
1# Zu .gitignore hinzufügen
2echo ".env" >> .gitignore
3echo ".env.local" >> .gitignore
4echo "*.key" >> .gitignore
5echo "*.pem" >> .gitignore
6echo "secrets.yml" >> .gitignore
1# Schlecht - .env-Datei
2DATABASE_PASSWORD=SuperSecret123
3
4# Gut - .env-Datei mit 1Password-Verweisen
5DATABASE_PASSWORD=op://Production/Database/password
1# Für statische Rollen, manuelle Rotation auslösen
2vault write -f database/rotate-role/my-static-role
3
4# Oder dynamische Secrets verwenden, die automatisch ablaufen und rotieren
5vault read database/creds/readwrite # Jedes Mal neue Credentials!
Teilen Sie niemals Secrets über Umgebungen hinweg. Development sollte Development-Zugangsdaten verwenden, Production sollte Production-Zugangsdaten verwenden. Mit der Umgebungsdatei-Unterstützung von 1Password wird dies unkompliziert:
1# Development
2op run --env-file=.env.dev -- npm start
3
4# Staging
5op run --env-file=.env.staging -- npm start
6
7# Production
8op run --env-file=.env.prod -- npm start
Jede .env.*-Datei verweist auf verschiedene Tresore oder Elemente in 1Password, wodurch eine vollständige Trennung zwischen Umgebungen sichergestellt wird. Diese Isolation verhindert versehentlichen Produktionsdatenzugriff während der Entwicklung und begrenzt den Explosionsradius kompromittierter Zugangsdaten.
1# Vault-Richtlinie - nur Lesezugriff auf bestimmte Pfade
2path "secret/data/myapp/*" {
3 capabilities = ["read", "list"]
4}
5
6path "secret/data/shared/*" {
7 capabilities = ["read", "list"]
8}
Gewähren Sie nur die minimal notwendigen Berechtigungen. Anwendungen sollten nur Secrets lesen, nicht schreiben oder löschen. Service-Konten sollten nur auf die spezifischen Pfade zugreifen, die sie benötigen. Dieser richtlinienbasierte Ansatz bedeutet, dass eine kompromittierte Anwendung ihre Berechtigungen nicht eskalieren oder auf Secrets zugreifen kann, die sie nicht benötigt.
Umfassende Audit-Protokollierung ist entscheidend für Sicherheits-Compliance und Incident Response. Aktivieren Sie sie frühzeitig:
1# Vault-Audit-Protokollierung
2vault audit enable file file_path=/var/log/vault-audit.log
3
4# Anzeigen, wer auf welches Secret zugegriffen hat
5cat /var/log/vault-audit.log | jq '.request.path'
Jeder Secret-Zugriff, Authentifizierungsversuch und Richtlinienänderung wird mit vollständigem Kontext protokolliert: wer die Anfrage gestellt hat, wann, von welcher IP-Adresse und ob sie erfolgreich war. Dieser Audit-Trail ist von unschätzbarem Wert für Sicherheitsuntersuchungen, Compliance-Audits und das Verständnis von Nutzungsmustern.
Zugangsdaten aus Code und Konfigurationsdateien fernzuhalten ist nicht nur eine Best Practice - es ist für die Sicherheit unerlässlich. Sowohl 1Password als auch HashiCorp Vault bieten leistungsstarke Lösungen:
Der Schlüssel liegt darin, das Secret-Management reibungslos zu gestalten. Wenn es einfacher ist, op run oder das Vault SDK zu verwenden als ein Passwort fest zu codieren, werden Entwickler natürlich das Richtige tun.
Fangen Sie klein an: Wählen Sie ein Projekt aus, ersetzen Sie seine fest codierten Zugangsdaten durch Umgebungsvariablen und verwenden Sie op run oder Vault, um sie zu injizieren. Sie werden sofort die Vorteile sehen und können von dort aus erweitern.
Ihr zukünftiges Ich (und Ihr Sicherheitsteam) wird es Ihnen danken.
Das Problem: Fest codierte Zugangsdaten Jeder Entwickler hat diese Versuchung schon erlebt: Sie müssen schnell etwas testen, also codieren Sie einen
Wie Claude Sonnet 4.5 und GitHub Copilot uns durch das Labyrinth von Custom-Backstage-Integrationen geholfen haben Das Backstage-Versprechen (und die Realität)
Kurzer Read (~6–7 Min) – fokussiert auf den operativen Teil der Model Context Protocol (MCP) Enablement. 1. Praxisproblem Ein einzelner MCP-Server ist trivial.
Einleitung Reiner Modellzugriff erzeugt selten nachhaltigen Unternehmensnutzen. Wirklicher Hebel entsteht, wenn Sprachmodelle sicher Werkzeuge aufrufen können
Das Container-Ökosystem hat sich in den letzten Jahren erheblich weiterentwickelt, und Teams haben heute mehr Wahlmöglichkeiten als je zuvor bei der Auswahl
Sie interessieren sich für unsere Trainings oder haben einfach eine Frage, die beantwortet werden muss? Sie können uns jederzeit kontaktieren! Wir werden unser Bestes tun, um alle Ihre Fragen zu beantworten.
Hier kontaktieren
