Secret management in Omada Identity Cloud Private
This page describes best practices for managing secrets in Omada Identity Cloud Private deployments. It is intended for customers and administrators who are responsible for the security of their Omada Identity Cloud Private deployment, including the Terraform state file and any secrets stored in it.
Overview: current state
In the current version of Omada Identity Cloud Private, Terraform provisions the Azure Key Vault and creates the initial secrets required by the platform. Because Terraform stores all known values in its state, this state file is the primary place where secret values may be exposed.
Secret values may appear in plain text inside the customer-managed Terraform state, which is stored in an Azure Storage Account.
At this stage of the product, securing these secrets is the customer's responsibility. This page describes recommended approaches to minimize the risk of exposure until further secret-management capabilities are introduced.
Restrict access to the Terraform state storage account
The Terraform state file is the primary location where secret values may be exposed. Limiting access to this storage account significantly reduces the impact of a potential breach.
Recommended actions:
- Use Azure RBAC instead of storage account access keys.
- Grant only CI/CD pipelines and a minimal set of administrators the Storage Blob Data Contributor role.
- Deny read access to all other users and service principals.
- Disable public network access, and expose the storage account only through a Private Endpoint.
- Ensure the Terraform backend uses Azure AD authentication.
Restricting access this way ensures that only tightly controlled identities can read the state file, preventing accidental or malicious access.
Enable customer-managed keys and immutable storage
Even if the storage account is compromised, encryption and immutability provide strong additional protection.
Recommended actions:
- Enable Customer-Managed Key (CMK) encryption using a Key Vault-managed key.
- Turn on immutable blob policies (WORM) to prevent tampering.
- Enable blob versioning and soft delete for recovery and auditability.
With CMK and immutable storage enabled, secrets stored in the Terraform state cannot be decrypted without access to the CMK, and immutable storage prevents unauthorized modification.
Use Terraform Cloud or Terraform Enterprise for state management
If permitted by your environment, Terraform Cloud or Terraform Enterprise provides more secure state storage as an alternative to a customer-managed Azure Storage Account.
Recommended actions:
- Store state in Terraform Cloud or Terraform Enterprise instead of Azure Storage.
- Use workspace-level role-based access control (RBAC) to restrict who can view or download state.
- Built-in encryption, secret masking, and audit logging provide additional protection.
This approach keeps state encrypted, access-controlled, and centrally audited, reducing exposure compared to a customer-managed storage account.
Monitor and audit access to the storage account
Recommended actions:
- Enable Azure Monitor diagnostic logs for blob read and write operations.
- Enable Microsoft Defender for Storage for anomaly detection.
- Configure alerts for:
- Unusual IP addresses.
- Unexpected principals accessing the container.
- Bulk downloads.
- Access key usage.
- Periodically review access logs and RBAC assignments.
Monitoring and auditing access provides early detection of suspicious activity and supports forensic analysis in case of an incident.