Each Autonomous Database (ADB) comes with a predefined database user called ADMIN that allows you to monitor and administer your database. The scope of ADMIN’s capabilities includes (but not limited to) the ability to create other database users, grant roles or privileges to other users, enable/disable certain features and so on. As you can see, it’s an extremely important task to manage and protect this user. Setting the ADMIN password during provisioning or resetting it after provisioning is a straightforward and secure process when done in OCI Console. Similar to many other ADB capabilities, these operations can also be performed via the OCI REST APIs. In this short blog post, we are going to go over how to securely handle setting or resetting the ADMIN password in OCI REST API calls using OCI Vault secrets.

The existing REST APIs support providing the ADMIN password either as a plain text or as a secret. However, embedding your user password as plain text into your scripts is not a good practice for obvious reasons. To avoid such security risks, you can easily store your ADMIN password in OCI Vault as a secret and use that secret in your API calls. In the remainder of this blog post, I’ll demonstrate how to provision an ADB instance using OCI CLI that accepts the ADMIN password as an OCI Vault secret. Here are the detailed steps that I will follow:

  • Create a secret in OCI Vault to store ADMIN password
  • Create an Autonomous Database

Create a secret in OCI Vault to store ADMIN password

In this step, I’ll be creating a secret in my vault and store my ADMIN password. To be able to do this in OCI CLI, I need the following:

  • A vault in OCI Vault
  • An AES key from the same or a different vault to encrypt my secret
  • The following OCI IAM policy that will allow my IAM user to create a secret in a vault:
    Allow group {yourUserGroup} to manage secret-family in {yourCompartment}

Then I’ll create my secret on OCI CLI (note the masked secret content, which I will use as my ADMIN password later):

> oci vault secret create-base64 --compartment-id ocid1.tenancy.oc1..aabq --secret-name tuzlasecret --vault-id ocid1.vault.oc1.iad.bfqua --secret-content-content ***********  --key-id ocid1.key.oc1.iad.abuwa             
                                                                  
{
  "data": {
    "compartment-id": "ocid1.tenancy.oc1..aabq",
    "current-version-number": 1,
    "defined-tags": {},
    "description": null,
    "freeform-tags": {},
    "id": "ocid1.vaultsecret.oc1.iad.amuqa",
    "key-id": "ocid1.key.oc1.iad.abuwa",
    "lifecycle-details": null,
    "lifecycle-state": "CREATING",
    "metadata": null,
    "secret-name": "tuzlasecret",
    "secret-rules": null,
    "time-created": "2023-02-15T00:25:36.387000+00:00",
    "time-of-current-version-expiry": null,
    "time-of-deletion": null,
    "vault-id": "ocid1.vault.oc1.iad.bfqua"
  }
}

Create an Autonomous Database

The next and final step is to create an Autonomous Database using OCI CLI. Similar to the previous step, I again need an OCI IAM policy for my OCI user to be able to access the secret:

Allow group {yourUserGroup} to read secret-family in {yourCompartment}

Please note that if you already the have the policy defined in the previous step, you don’t need this one since ‘manage’ is a superset of ‘read’ in terms of policy scope. If you already have a secret and only need ‘read‘ access for setting or resetting your ADMIN password then simply just using the ‘read’ policy above will be sufficient.

Let’s create our Autonomous Database (note the secret OCID as opposed to plain text ADMIN password as the input):

> oci db autonomous-database create --compartment-id ocid1.tenancy.oc1..aabq --display-name secretdemo --db-name secretdemo --cpu-core-count 1 --data-storage-size-in-tbs 1 --secret-id ocid1.vaultsecret.oc1.iad.amuqa 

{
  "data": {
    "autonomous-maintenance-schedule-type": "REGULAR",
    "compartment-id": "ocid1.tenancy.oc1..aabq",
    "compute-count": 1.0,
    "compute-model": "OCPU",
    "cpu-core-count": 1,
    "data-storage-size-in-gbs": 1024,
    "data-storage-size-in-tbs": 1,
    "database-edition": "ENTERPRISE_EDITION",
    "db-name": "secretdemo",
    "db-workload": "OLTP",
    "display-name": "secretdemo",
    "id": "ocid1.autonomousdatabase.oc1.iad.anua",
    ...
  },
  "opc-work-request-id": "ocid1.coreservicesworkrequest.oc1.iad.abq"
}

To summarize, ADMIN is database user that is provided out-of-the-box with each Autonomous Database, and various administrative tasks in your database can be performed with this user. Given the critical role of ADMIN in ADB, managing and securing this account is quite important. Setting or updating ADMIN password in OCI Console is well protected by different security measures. In this blog post, we have seen how similar measures (such as obtaining the user password from OCI Vault as opposed to providing it in plain text) can be adopted for OCI REST APIs as well for those who have scripts to handle these operations. For more details on using secrets for storing ADMIN password, please see our documentation.