Security and access should be explicit
This page documents the security model being prepared for Azure VM Manager. Items that still require implementation or formal approval are intentionally labeled instead of presented as completed controls.
Azure access model
Azure VM Manager is intended to operate with customer-approved Azure access. Required roles and scopes will be documented during onboarding so permissions can be assigned at the narrowest practical scope.
Secrets and identity
The target production design uses managed identities and Azure Key Vault for service identity and secret handling. Static secrets should not be embedded in application code or public configuration.
Operational records
The product records requests, status, execution results, and audit context so teams can review who requested an action, what was targeted, and how the operation completed.
Queue-backed execution
The launch architecture moves long-running Azure VM actions from the API process into a worker behind Azure Service Bus, improving separation between request intake and operation execution.
What Azure VM Manager is not intended to do
Review items before launch
These details must be verified against the application before stronger public claims are made.
- Exact Azure RBAC roles and minimum scopes for each supported operation
- Authentication, authorization, and tenant-isolation implementation evidence
- Retry, timeout, duplicate-detection, dead-letter, poison-message, and cancellation policies
- Data retention, deletion, subprocessors, and incident-response commitments
Security contact
For security questions or vulnerability reports, contact the 143IT team by email. Include affected systems, reproduction steps, and any relevant timestamps.