Anmerkung
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Rost-Anwendungen müssen sich bei Azure-Diensten wie Speicher, Key Vault oder Cosmos DB authentifizieren. In diesem Artikel wird erläutert, wie Sie die Azure Identity-Rate verwenden, um Rost-Apps in lokalen Entwicklungs- und Serverumgebungen sicher zu authentifizieren, die Sicherheit zu verbessern und die Verwaltung von Anmeldeinformationen zu vereinfachen.
Empfohlene tokenbasierte Authentifizierung
Der empfohlene Ansatz besteht darin, dass Ihre Apps bei der Authentifizierung für Azure-Ressourcen tokenbasierte Authentifizierung anstelle von Verbindungszeichenfolgen oder Schlüsseln verwenden. Die azure_identity Rate bietet tokenbasierte Authentifizierung und ermöglicht Apps die nahtlose Authentifizierung bei Azure-Ressourcen, unabhängig davon, ob sich die App in der lokalen Entwicklung befindet, in Azure bereitgestellt oder auf einem lokalen Server bereitgestellt wird.
Die spezifische Art der tokenbasierten Authentifizierung, die eine App für die Authentifizierung bei Azure-Ressourcen verwenden soll, hängt davon ab, wo die App ausgeführt wird.
| Umwelt | Authentifizierung |
|---|---|
| Lokal | Wenn ein Entwickler eine App während der lokalen Entwicklung ausführt – Die App kann sich mit den lokalen Anmeldeinformationen des Entwicklers bei Azure authentifizieren. Diese Optionen werden im crates.io ausführlicher bereitgestellt : Authentifizieren mit Entwicklungstools. |
| Azure | Wenn eine App in Azure gehostet wird – Die App sollte sich mit einer verwalteten Identität bei Azure-Ressourcen authentifizieren. Diese Option wird in der dokumentation crates.io ausführlicher erläutert: Authentifizieren von von Azure gehosteten Anwendungen. |
| Lokal | Wenn eine App lokal gehostet und bereitgestellt wird – Die App sollte sich mit einem Anwendungsdienstprinzipal bei Azure-Ressourcen authentifizieren. Diese Option wird in der dokumentation crates.io erläutert: Authentifizieren von Dienstprinzipalen. |
Vorteile der tokenbasierten Authentifizierung
Beim Erstellen von Apps für Azure wird dringend empfohlen, die tokenbasierte Authentifizierung anstelle von geheimen Schlüsseln wie Verbindungszeichenfolgen oder Schlüsseln zu verwenden.
| Tokenbasierte Authentifizierung | Geheime Schlüssel (Verbindungszeichenfolgen und Schlüssel) |
|---|---|
| Prinzip der geringsten Berechtigung, richten Sie die spezifischen Berechtigungen ein, die von der App für die Azure-Ressource benötigt werden. | Eine Verbindungszeichenfolge oder ein Schlüssel gewährt der Azure-Ressource vollständige Rechte. |
| Es ist kein Anwendungsgeheimnis zum Speichern vorhanden. | Muss geheime Schlüssel in der App-Einstellung oder Umgebungsvariable speichern und drehen. |
| Die Azure Identity-Bibliothek verwaltet Token für Sie hinter den Kulissen. Dies erleichtert die Verwendung der tokenbasierten Authentifizierung als Verbindungszeichenfolge. | Geheime Schlüssel werden nicht verwaltet. |
Die Verwendung von Verbindungszeichenfolgen sollte auf den anfänglichen Nachweis von Konzept-Apps oder Entwicklungsprototypen beschränkt sein, die nicht auf Produktionsdaten oder vertrauliche Daten zugreifen. Andernfalls sollten die tokenbasierten Authentifizierungsklassen, die in der Azure Identity-Bibliothek verfügbar sind, immer bevorzugt werden, wenn Sie sich bei Azure-Ressourcen authentifizieren.
Authentifizieren während der lokalen Entwicklung
Wenn eine Anwendung während der lokalen Entwicklung auf der Arbeitsstation eines Entwicklers ausgeführt wird, muss sich die lokale Umgebung bei allen von der App verwendeten Azure-Diensten authentifizieren.
Authentifizieren mit Azure CLI-Anmeldeinformationen
Die Azure CLI-Anmeldeinformationen verwenden den Authentifizierungsstatus der Azure CLI, um Ihre Rust-Anwendung zu authentifizieren. Diese Anmeldeinformationen eignen sich ideal für die lokale Entwicklung, wenn Sie bereits angemeldet az loginsind.
use azure_identity::AzureCliCredential;
use azure_security_keyvault_secrets::SecretClient;
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
dotazure::load()?;
let vault_url = std::env::var("AZURE_KEYVAULT_URL")
.map_err(|_| "AZURE_KEYVAULT_URL environment variable is required")?;
let credential = AzureCliCredential::new(None)?;
let client = SecretClient::new(&vault_url, credential.clone(), None)?;
Ok(())
}
Authentifizieren mit Azure Developer CLI-Anmeldeinformationen
Die Anmeldeinformationen der Azure Developer CLI verwenden den Authentifizierungsstatus der Azure Developer CLI (azd) zur Authentifizierung Ihrer Anwendung. Diese Anmeldeinformationen sind hilfreich beim Arbeiten mit azd-Vorlagen und Workflows.
use azure_identity::AzureDeveloperCliCredential;
use azure_security_keyvault_secrets::SecretClient;
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
dotazure::load()?;
let vault_url = std::env::var("AZURE_KEYVAULT_URL")
.map_err(|_| "AZURE_KEYVAULT_URL environment variable is required")?;
let credential = AzureDeveloperCliCredential::new(None)?;
let client = SecretClient::new(&vault_url, credential.clone(), None)?;
Ok(())
}
Authentifizieren in Serverumgebungen
Verwenden Sie in Serverumgebungen verwaltete Identitäten für sichere, kennwortlose Authentifizierung. Verwaltete Identitäten werden automatisch von Azure erstellt und verwaltet, sodass Ihre Anwendung sich authentifizieren kann, ohne Anmeldeinformationen speichern zu müssen.
Weisen Sie beim Hosten in einer Serverumgebung jeder Anwendung für jede Umgebung eine eindeutige Anwendungsidentität zu. In Azure wird eine App-Identität durch einen Dienstprinzipal dargestellt, einen speziellen Sicherheitsprinzipal, der Apps für Azure identifiziert und authentifiziert. Der Dienstprinzipaltyp, den Sie für Ihre App verwenden, hängt davon ab, wo Ihre App ausgeführt wird.
use azure_identity::{ManagedIdentityCredential, ManagedIdentityCredentialOptions, UserAssignedId};
use azure_security_keyvault_secrets::SecretClient;
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
dotazure::load()?;
let vault_url = std::env::var("AZURE_KEYVAULT_URL")
.map_err(|_| "AZURE_KEYVAULT_URL environment variable is required")?;
let user_assigned_id: Option<UserAssignedId> = std::env::var("AZURE_USER_ASSIGNED_IDENTITY")
.ok()
.map(|id| UserAssignedId::ClientId(id.clone()));
let credential_options = ManagedIdentityCredentialOptions {
user_assigned_id,
..Default::default()
};
let credential = ManagedIdentityCredential::new(Some(credential_options))?;
let client = SecretClient::new(vault_url.as_str(), credential.clone(), None)?;
Ok(())
}
Beispielcode
Der in diesem Artikel gezeigte Code ist verfügbar auf https://github.com/azure-samples/azure-sdk-for-rust-docs/.
Weitere Ressourcen
- Azure SDK-Krates auf Crates.io – Liste der verfügbaren Azure SDK-Krates
- Entwurfsrichtlinien für Das Azure SDK – Designprinzipien und -muster
- Azure SDK für Rust GitHub-Repository – Probleme und Quellcode
- Frachtdokumentation - Vollständige Frachtreferenz