Manage Azure Key Vault Keys with Rust SDK

The azure_security_keyvault_keys Rust crate is the client library for Azure Key Vault's key storage and management, covering RSA (2048/3072/4096-bit), elliptic curve (P-256, P-384, P-521), and hardware-protected RSA-HSM/EC-HSM keys. A KeyClient, authenticated via DeveloperToolsCredential (or ManagedIdentityCredential in production) against a vault URL, exposes get_key, create_key (with CreateKeyParameters specifying kty/key_size for RSA or kty/curve for EC), delete_key, a paged list_key_properties stream, and backup_key/restore_key for disaster recovery - backup_key returns opaque bytes meant to be stored safely and fed back into restore_key later.

Use this skill when a Rust application needs centrally-managed cryptographic keys - for encryption, signing, or key wrapping - without ever handling raw private key material in application code, since Key Vault performs the actual crypto operations (encrypt/decrypt, sign/verify, wrapKey/unwrapKey) server-side depending on key type and the caller's assigned permissions. It is the keys API specifically; secrets and certificates are separate Key Vault APIs not covered here.

Inputs are a vault URL (AZURE_KEYVAULT_URL) and, per operation, a key name plus type-specific parameters - KeyType::Rsa with a key_size, or KeyType::Ec with a CurveName like P256. Outputs are key model objects exposing the key's ID (kid) and metadata; list_key_properties returns an async pager whose items expose a resource_id() with the key's name, and backup_key returns raw backup bytes rather than a key object.

cargo add azure_security_keyvault_keys azure_identity

Built on azure_identity for Entra ID authentication and futures' TryStreamExt for paging through list_key_properties. Access is governed by Key Vault RBAC roles: Key Vault Crypto User for using keys in crypto operations, and Key Vault Crypto Officer for full CRUD on key objects themselves.

Rust developers building applications that need centrally-managed, auditable cryptographic keys - encrypting sensitive data, signing tokens or documents, or wrapping other keys - rather than embedding key material directly. The skill's own best practices recommend EC keys for signing (more efficient than RSA), RSA for encryption, HSM-backed keys for the most sensitive workloads, regular backups for disaster recovery, enabling soft delete (required for production vaults), and periodic key rotation by creating new key versions rather than reusing one indefinitely. Because the vault performs cryptographic operations itself, the same key can back both a signing workflow and an encryption workflow across multiple services without any of them ever needing direct access to the underlying key bytes, which keeps the blast radius of a compromised service limited to what that service's RBAC role permits.