Using OCI Vault Secrets for Terraform resources

March 22, 2022 | 4 minute read
Text Size 100%:

Using passwords and other credentials securely in Infrastructure-as-Code projects is crucial. Storing credentials in plain text in the code or related configuration files is to be avoided at all cost as it is a major security risk.

This post is written with the intention to complement the excellent “A comprehensive guide to managing secrets in your Terraform code” by Yevgeniy Brikman. Its aim is to detail how Oracle Cloud Infrastructure Vault (OCI Vault) can be used to securely store credentials and subsequently use them in Terraform scripts.

Whilst this is without a doubt a great step towards safer code management, there is still an unsolved issue with Terraform: the state file is considered sensitive information by HashiCorp. When using the local backend for storing the state file-the default-passwords and other sensitive information are stored in clear text in a JSON file, very much counter-productive to the article’s goals. Alternative backends are most likely better suited. Please ensure you remain compliant with your IT security department’s security requirements regarding the Terraform state file.


In this article you can read about the creation of an Autonomous Database using a small Terraform script. Rather than providing the ADB instanace's ADMIN password as an environment variable, the password is retrieved from an OCI Vault secret.

Oracle Cloud Infrastructure Vault

OCI Vault is a managed service that lets you centrally control the encryption keys that protect your data and the secret credentials that you use to securely access resources. Vaults securely store master encryption keys and secrets that you might otherwise store in less secure places elsewhere.

Secrets in the context of OCI Vault are credentials such as passwords, certificates, SSH keys, or authentication tokens that you use with Oracle Cloud Infrastructure services. An OCI Vault Secret cannot be looked up as such: secrets are wrapped in secret bundles. A secret bundle consists of the secret contents, properties of the secret and secret version (such as version number or rotation state), and user-provided contextual metadata for the secret.

To keep this article short, it is assumed that a secret has already been created and its Oracle Cloud Identifier (OCID) is known. The secret's OCID is passed to the Terraform script via a variable.

Autonomous Database

Oracle Cloud Infrastructure's Autonomous Database is a fully managed, preconfigured database environment. An Autonomous Database (ADB) instance is perfectly suited to demonstrate the use of a Terraform Data Source for looking up vault secrets as it does not require any supporting resources such as Virtual Cloud Networks, or any elaborate network security settings. The Terraform script will create a publicly accessible ADB instance protected by an Access Control List (ACL) allowing only specific IP addresses to connect. Furthermore mutual TLS is enabled for better security.

Performing a Lookup Operation

Lookup operations in Terraform are performed using Data Sources. There are data sources for most cloud resources, including the aforementioned secret bundle. Provided the secret's OCID is passed via a variable, the lookup using an oci_secrets_secretbundle data source could be performed as follows:

data "oci_secrets_secretbundle" "bundle" {
  secret_id = var.secret_ocid

Thankfully the OCI Terraform provider is smart enough to retrieve the current, active version of the secret. Once the secret has been retrieved, it can be used for the creation of an ADB instance. Since secrets are base64 encoded, they have to be decoded before they can be used. The following snippet demonstrates the use of the data source inside the ADB resource:

resource "oci_database_autonomous_database" "demo_adb_21c" {
  compartment_id              = var.compartment_ocid
  db_name                     = "DEMO"
  admin_password              = base64decode(data.oci_secrets_secretbundle.bundle.secret_bundle_content.0.content)
  cpu_core_count              = 1
  data_storage_size_in_tbs    = 1
  db_version                  = "21c"
  db_workload                 = "OLTP"
  display_name                = "ADB Free Tier 21c"
  is_free_tier                = true
  is_mtls_connection_required = true
  ocpu_count                  = 1
  whitelisted_ips             = var.allowed_ip_addresses

A call to terraform plan followed by a terraform apply will initiate the creation of the ADB instance. As long as the admin password complies with the password complexity rules of the ADB resource, the database will be created. Once its lifecycle status changed to running, the database will be accessible to IP addresses specified in var.allowed_addresses (a list of strings).


Using OCI Vault to store sensitive information is a secure way to mitigate against many password-handling problems. The Terraform state file remains a concern, especially when using the local backend as it stores all information in clear text. The IT security department should be consulted as to how this potential security vulnerability should be treated. Other backends than the local backend exist and might suit the IT security team's needs better.

Once a Vault secret has been looked up, it can be used in any Terraform resource. Referencing data sources should lead to more secure code deployments.

Happy Automating!


Martin Bach

Martin is a product manager at Oracle helping customers in Europe and around the world address their IT related problems. He is most interested in cloud technology, DevOps and how these can be used best with Oracle technology.

Previous Post

Oracle Database API for MongoDB

Roger Ford | 13 min read

Next Post

Retrospective: Pi Day 2022

Erin Dawson | 2 min read