Enabling MFA for IDCS User Accounts in OCI

OCI has two types of user accounts IAM native and IDCS (also refered to as federated user accounts). For IAM accounts user has to enable MFA for their own account. Admin cannot enable MFA for another account. For federated accounts either tenancy admin or a user in IDCS_Administrators group must first setup MFA. Afterwards users can enroll themselves for MFA. This post shows steps for setting up MFA on IDCS.
The steps beging with the assumption that user (tenancy admin or user in IDCS_Administrators group) has already login to the IDCS console.
First step is to configure the factors used for MFA. This include deciding on the hashing algorithm used for passcode generation, how long a passcode is valid and etc. During the initial setup MFA with mobile app is setup (it's best practice to have two different type of MFA. Email based MFA will be setup afterwards).
On the IDCS console select the top left menu and expand Security and select Factors menu item. Select the mobile app tab and configure mobile app MFA related properties.

Next select MFA menu item under security menu and check the mobile app passcode. Both mobile app passcode and notification are selected by default. Click save to confirm the changes.

Third step is to enforce the MFA. This is done via a Sign-On policies. There's a default sign-on policy already created. It is possible to edit the existing one or add a new one.

For this post a new policy is created for MFA. Click add to begin the wizard. First item is the policy name. Click next to proceed to creating a sign-on rule.

A sign-on rule is created such that if a login is done using username and password then additional authentication factors are prompted. Since currently only mobile app passcode and notification are setup these options are selected as additonal factors. MFA prompt is set for everytime a login is done and enrollment is set for optional. This is useful until MFA setup is completed and verified.

The saved sign-on rule will be listed as below.

Next step is to add an app to the sign-on policy. For this select the automatically created SAML app which has the OCI-V2-App"tenancy name" as the name. Oracle doc describe this as

In order for MFA to be prompted this app must be selected. Without it no MFA will be prompted. In the apps tab select assign and search for the above app (applicable to the current tenancy) and select.

At this stage the sign-on rule is in inactive state. Select the menu next to the rule and activate it.

Next login to OCI console as a federated user. Even though enrollment was set to optional the console does prompt user to enable MFA (it is always possible to skip this and enable MFA later via IDCS console. Shown later in the post). To enable MFA enable secure verification button.

This will present a QR code that is compatible with Oracle mobile authenticator (OMA) app. If not alreayd done, download OMA app to phone and scan the QR code to add the account (i.e enroll to MFA). This QR code will not work with google authenticator. If google authenticator is desired then select use another authenticator app.

As mentioned earlier it is possible to enroll to MFA later on via IDCS console. Below screenshots show these steps. Login to IDCS console as the user that need MFA enabling. Select My Profile and then the security tab. Click enable button for 2-step verification.

Since only mobile app is enabled for MFA, the 2-step vericiation list mobile app. Click the mobile app button and scan the QR code as mentioned before.

Once done the device will be listed under mobile app.

Next time when the IDCS (federated) user login the MFA is prompted. Could use both mobile app notification (select allow on the mobile phone) or entering the passcode (alternative method).

As mentioned in the begining it is considered best practice to have two MFA methods. If only mobile app based MFA is configured then loss of the phone means unable to access the account and have to go through the recovery option. Below steps shows how to add email based MFA after adding the mobile app bsaed MFA (it is possible to setup both these options at the same time as well. No need to do one after another).
In the IDCS console expand security and then select factors. In the email tab configure MFA related properties.

Select MFA and check the email checkbox. Since mobile app is already configured those would have been already checked.

Next need to edit the sign-on policy created earlier. Select the policy menu and click on edit.

Select the sign-on rule inside the policy and select edit.

In the rule select email as an additional factor for authentication. This will already have mobile app selected.

To enroll email based MFA login as the user enabling MFA to the IDCS console (My profile -> security) and select configure on email option.

This will send a passcode to the email in the account. Enter the passcode to verify the email address. Once verified email will be added to MFA.

Next time when user login email is also presented as an alternative login method. When selected passcode is sent to the email.

Update 26 September 2023
With the recent changes to IDCS and IAM domains the above MFA setup will not work. To get MFA working again enable the "Security Policy for OCI Console" policy. This is provided by Oracle and will be in disable state.

Inside are two rules, one for admins and one for all users. If needed tweak them if not leave as it is.

This policy has the "OCI Console" as the app. No need to change it leave it as it is. "MFA Policy" created earlier could be deactivated now. All the previously registered MFA methods (mobile app, email) will work as before without re-regise

Patching OS in DBCS VM DB Using DBCLI

There's an earlier post which shows updating and patching the OS. This method used yum to update the OS. It is still valid and available in documentation as well.
Recently Oracle introduced a new way to patch the OS, that is using the dbcli. The dbcli is the tool to use if patching the DB is done using command line. With this new enhancement same tool dbcli could be used to patching and updating the OS as well.
1. To check if any OS updates are available run the get-availableospatches command. If patches are not available updateAvailable will show false.

#  dbcli get-availableospatches -j
{
  "updateAvailable" : false,
  "rebootIsRequired" : false,
  "updateableRpms" : null,
  "installedRpms" : null
}

2. If updates are available then it will show updateAvailable true and also if a reboot is required after update.

dbcli get-availableospatches
Update Available     Reboot Required
-------------------- --------------------
Yes                  Yes

To get a list of rpms update use -j option.

bcli get-availableospatches -j
{
  "updateAvailable" : true,
  "rebootIsRequired" : true,
  "updateableRpms" : [ "bind.x86_64::32:9.11.4-26.P2.el7_9.5", "bind-export-libs.x86_64::32:9.11.4-26.P2.el7_9.5", "bind-libs.x86_64::32:9.11.4-26.P2.el7_9.5", "bind-libs-lite.x86_64::32:9.11.4-26.P2.el7_9.5", "bind-license.noarch::32:  9.11.4-26.P2.el7_9.5", "bind-utils.x86_64::32:9.11.4-26.P2.el7_9.5", "curl.x86_64::7.29.0-59.0.3.el7_9.1", "device-mapper.x86_64::7:1.02.170-6.0.5.el7_9.5", "device-mapper-event.x86_64::7:1.02.170-6.0.5.el7_9.5", "device-mapper-event-l  ibs.x86_64::7:1.02.170-6.0.5.el7_9.5", "device-mapper-libs.x86_64::7:1.02.170-6.0.5.el7_9.5", "device-mapper-multipath.x86_64::0.4.9-134.0.3.el7_9", "device-mapper-multipath-libs.x86_64::0.4.9-134.0.3.el7_9", "dhclient.x86_64::12:4.2.5  -83.0.1.el7_9.1", "dhcp.x86_64::12:4.2.5-83.0.1.el7_9.1", "dhcp-common.x86_64::12:4.2.5-83.0.1.el7_9.1", "dhcp-libs.x86_64::12:4.2.5-83.0.1.el7_9.1", "dmidecode.x86_64::1:3.2-5.0.1.el7_9.1", "glib2.x86_64::2.56.1-9.el7_9", "glibc.i686:  :2.17-324.0.1.el7_9", "glibc.x86_64::2.17-324.0.1.el7_9", "glibc-common.x86_64::2.17-324.0.1.el7_9", "glibc-devel.x86_64::2.17-324.0.1.el7_9", "glibc-headers.x86_64::2.17-324.0.1.el7_9", "grub2.x86_64::1:2.02-0.87.0.9.el7_9.6", "grub2-  common.noarch::1:2.02-0.87.0.9.el7_9.6", "grub2-efi-x64.x86_64::1:2.02-0.87.0.9.el7_9.6", "grub2-pc.x86_64::1:2.02-0.87.0.9.el7_9.6", "grub2-pc-modules.noarch::1:2.02-0.87.0.9.el7_9.6", "grub2-tools.x86_64::1:2.02-0.87.0.9.el7_9.6", "g  rub2-tools-extra.x86_64::1:2.02-0.87.0.9.el7_9.6", "grub2-tools-minimal.x86_64::1:2.02-0.87.0.9.el7_9.6", "gssproxy.x86_64::0.7.0-30.el7_9", "hwdata.x86_64::0.252-9.7.0.1.el7", "iscsi-initiator-utils.x86_64::6.2.0.874-20.0.5.el7_9", "i  scsi-initiator-utils-iscsiuio.x86_64::6.2.0.874-20.0.5.el7_9", "kernel-devel.x86_64::3.10.0-1160.36.2.el7", "kernel-headers.x86_64::3.10.0-1160.36.2.el7", "kernel-uek.x86_64::4.1.12-124.53.5.el7uek", "kernel-uek-firmware.noarch::4.1.12  -124.53.5.el7uek", "kexec-tools.x86_64::2.0.15-51.0.3.el7_9.3", "kpartx.x86_64::0.4.9-134.0.3.el7_9", "krb5-libs.x86_64::1.15.1-50.0.1.el7", "libcurl.x86_64::7.29.0-59.0.3.el7_9.1", "libgudev1.x86_64::219-78.0.5.el7_9.3", "libipa_hbac.  x86_64::1.16.5-10.0.1.el7_9.8", "libldb.x86_64::1.5.4-2.el7_9", "libsmbclient.x86_64::4.10.16-15.el7_9", "libsss_autofs.x86_64::1.16.5-10.0.1.el7_9.8", "libsss_certmap.x86_64::1.16.5-10.0.1.el7_9.8", "libsss_idmap.x86_64::1.16.5-10.0.1  .el7_9.8", "libsss_nss_idmap.x86_64::1.16.5-10.0.1.el7_9.8", "libsss_sudo.x86_64::1.16.5-10.0.1.el7_9.8", "libwbclient.x86_64::4.10.16-15.el7_9", "libxml2.i686::2.9.1-6.0.3.el7.5", "libxml2.x86_64::2.9.1-6.0.3.el7.5", "libxml2-python.x  86_64::2.9.1-6.0.3.el7.5", "linux-firmware.noarch::999:20210617-999.8.git0f66b74b.el7", "lvm2.x86_64::7:2.02.187-6.0.5.el7_9.5", "lvm2-libs.x86_64::7:2.02.187-6.0.5.el7_9.5", "mokutil.x86_64::15.3-1.0.5.el7", "nettle.x86_64::2.7.1-9.el  7_9", "nfs-utils.x86_64::1:1.3.0-0.68.0.1.el7.1", "nss.x86_64::3.53.1-7.el7_9", "nss-sysinit.x86_64::3.53.1-7.el7_9", "nss-tools.x86_64::3.53.1-7.el7_9", "openldap.x86_64::2.4.44-23.el7_9", "openssl.x86_64::1:1.0.2k-21.0.3.el7_9", "ope  nssl-libs.x86_64::1:1.0.2k-21.0.3.el7_9", "oracle-database-preinstall-19c.x86_64::1.0-3.el7", "pciutils.x86_64::3.5.1-3.0.1.el7", "pciutils-libs.x86_64::3.5.1-3.0.1.el7", "python.x86_64::2.7.5-90.0.3.el7", "python-libs.x86_64::2.7.5-90  .0.3.el7", "python-sssdconfig.noarch::1.16.5-10.0.1.el7_9.8", "redhat-release-server.x86_64::1:7.9-6.0.1.el7_9", "rsyslog.x86_64::8.24.0-57.0.1.el7_9.1", "samba-client-libs.x86_64::4.10.16-15.el7_9", "samba-common.noarch::4.10.16-15.el  7_9", "samba-common-libs.x86_64::4.10.16-15.el7_9", "screen.x86_64::4.1.0-0.27.20120314git3c2946.el7_9", "selinux-policy.noarch::3.13.1-268.0.13.el7_9.2", "selinux-policy-targeted.noarch::3.13.1-268.0.13.el7_9.2", "shim-x64.x86_64::15.  3-1.0.5.el7", "sos.noarch::3.9-5.0.11.el7_9.6", "sssd.x86_64::1.16.5-10.0.1.el7_9.8", "sssd-ad.x86_64::1.16.5-10.0.1.el7_9.8", "sssd-client.x86_64::1.16.5-10.0.1.el7_9.8", "sssd-common.x86_64::1.16.5-10.0.1.el7_9.8", "sssd-common-pac.x  86_64::1.16.5-10.0.1.el7_9.8", "sssd-ipa.x86_64::1.16.5-10.0.1.el7_9.8", "sssd-krb5.x86_64::1.16.5-10.0.1.el7_9.8", "sssd-krb5-common.x86_64::1.16.5-10.0.1.el7_9.8", "sssd-ldap.x86_64::1.16.5-10.0.1.el7_9.8", "sssd-proxy.x86_64::1.16.5  -10.0.1.el7_9.8", "systemd.x86_64::219-78.0.5.el7_9.3", "systemd-libs.x86_64::219-78.0.5.el7_9.3", "systemd-sysv.x86_64::219-78.0.5.el7_9.3", "unzip.x86_64::6.0-22.el7_9" ],
  "installedRpms" : [ "bind.x86_64::32:9.11.4-26.P2.el7_9.3", "bind-export-libs.x86_64::32:9.11.4-26.P2.el7_9.3", "bind-libs.x86_64::32:9.11.4-26.P2.el7_9.3", "bind-libs-lite.x86_64::32:9.11.4-26.P2.el7_9.3", "bind-license.noarch::32:9  .11.4-26.P2.el7_9.3", "bind-utils.x86_64::32:9.11.4-26.P2.el7_9.3", "curl.x86_64::7.29.0-59.0.1.el7_9.1", "device-mapper.x86_64::7:1.02.170-6.0.3.el7_9.3", "device-mapper-event.x86_64::7:1.02.170-6.0.3.el7_9.3", "7:1.02.170-6.0.3.el7_9  .3::@pdit_ol7_latest/$releasever", "device-mapper-libs.x86_64::7:1.02.170-6.0.3.el7_9.3", "0.4.9-134.0.1.el7_9::@pdit_ol7_latest/$releasever", "0.4.9-134.0.1.el7_9::@pdit_ol7_latest/$releasever", "dhclient.x86_64::12:4.2.5-82.0.1.el7",   "dhcp.x86_64::12:4.2.5-82.0.1.el7", "dhcp-common.x86_64::12:4.2.5-82.0.1.el7", "dhcp-libs.x86_64::12:4.2.5-82.0.1.el7", "dmidecode.x86_64::1:3.2-5.el7", "glib2.x86_64::2.56.1-8.el7", "glibc.i686::2.17-322.0.1.el7_9", "glibc.x86_64::2.  17-322.0.1.el7_9", "glibc-common.x86_64::2.17-322.0.1.el7_9", "glibc-devel.x86_64::2.17-322.0.1.el7_9", "glibc-headers.x86_64::2.17-322.0.1.el7_9", "grub2.x86_64::1:2.02-0.87.0.5.el7", "grub2-common.noarch::1:2.02-0.87.0.5.el7", "grub2  -efi-x64.x86_64::1:2.02-0.87.0.5.el7", "grub2-pc.x86_64::1:2.02-0.87.0.5.el7", "grub2-pc-modules.noarch::1:2.02-0.87.0.5.el7", "grub2-tools.x86_64::1:2.02-0.87.0.5.el7", "grub2-tools-extra.x86_64::1:2.02-0.87.0.5.el7", "grub2-tools-min  imal.x86_64::1:2.02-0.87.0.5.el7", "gssproxy.x86_64::0.7.0-29.el7", "hwdata.x86_64::0.252-9.7.el7", "6.2.0.874-20.0.1.el7_9::@pdit_ol7_latest/$releasever", "6.2.0.874-20.0.1.el7_9::@pdit_ol7_latest/$releasever", "kernel-devel.x86_64::3  .10.0-1160.15.2.el7", "kernel-headers.x86_64::3.10.0-1160.15.2.el7", "kernel-uek.x86_64::4.1.12-124.47.3.el7uek", "kernel-uek-firmware.noarch::4.1.12-124.47.3.el7uek", "kexec-tools.x86_64::2.0.15-51.0.3.el7_9.1", "kpartx.x86_64::0.4.9-  134.0.1.el7_9", "krb5-libs.x86_64::1.15.1-50.el7", "libcurl.x86_64::7.29.0-59.0.1.el7_9.1", "libgudev1.x86_64::219-78.0.1.el7_9.3", "libipa_hbac.x86_64::1.16.5-10.0.1.el7_9.7", "libldb.x86_64::1.5.4-1.el7", "libsmbclient.x86_64::4.10.1  6-9.el7_9", "libsss_autofs.x86_64::1.16.5-10.0.1.el7_9.7", "libsss_certmap.x86_64::1.16.5-10.0.1.el7_9.7", "libsss_idmap.x86_64::1.16.5-10.0.1.el7_9.7", "libsss_nss_idmap.x86_64::1.16.5-10.0.1.el7_9.7", "libsss_sudo.x86_64::1.16.5-10.0  .1.el7_9.7", "libwbclient.x86_64::4.10.16-9.el7_9", "libxml2.i686::2.9.1-6.0.1.el7.5", "libxml2.x86_64::2.9.1-6.0.1.el7.5", "libxml2-python.x86_64::2.9.1-6.0.1.el7.5", "linux-firmware.noarch::999:20200902-999.5.gitd5f9eea5.el7", "lvm2.  x86_64::7:2.02.187-6.0.3.el7_9.3", "lvm2-libs.x86_64::7:2.02.187-6.0.3.el7_9.3", "mokutil.x86_64::15-2.0.9.el7", "nettle.x86_64::2.7.1-8.el7", "nfs-utils.x86_64::1:1.3.0-0.68.0.1.el7", "nss.x86_64::3.53.1-3.el7_9", "nss-sysinit.x86_64:  :3.53.1-3.el7_9", "nss-tools.x86_64::3.53.1-3.el7_9", "openldap.x86_64::2.4.44-22.el7", "openssl.x86_64::1:1.0.2k-21.el7_9", "openssl-libs.x86_64::1:1.0.2k-21.el7_9", "1.0-2.el7::@pdit_ol7_latest/$releasever", "pciutils.x86_64::3.5.1-3  .el7", "pciutils-libs.x86_64::3.5.1-3.el7", "python.x86_64::2.7.5-90.0.1.el7", "python-libs.x86_64::2.7.5-90.0.1.el7", "python-sssdconfig.noarch::1.16.5-10.0.1.el7_9.7", "1:7.9-3.0.1.el7::@pdit_ol7_latest/$releasever", "rsyslog.x86_64:  :8.24.0-57.el7_9", "samba-client-libs.x86_64::4.10.16-9.el7_9", "samba-common.noarch::4.10.16-9.el7_9", "samba-common-libs.x86_64::4.10.16-9.el7_9", "screen.x86_64::4.1.0-0.26.20120314git3c2946.el7", "selinux-policy.noarch::3.13.1-268.  0.1.el7_9.2", "3.13.1-268.0.1.el7_9.2::@pdit_ol7_latest/$releasever", "shim-x64.x86_64::15-2.0.9.el7", "sos.noarch::3.9-5.0.3.el7_9.2", "sssd.x86_64::1.16.5-10.0.1.el7_9.7", "sssd-ad.x86_64::1.16.5-10.0.1.el7_9.7", "sssd-client.x86_64:  :1.16.5-10.0.1.el7_9.7", "sssd-common.x86_64::1.16.5-10.0.1.el7_9.7", "sssd-common-pac.x86_64::1.16.5-10.0.1.el7_9.7", "sssd-ipa.x86_64::1.16.5-10.0.1.el7_9.7", "sssd-krb5.x86_64::1.16.5-10.0.1.el7_9.7", "sssd-krb5-common.x86_64::1.16.  5-10.0.1.el7_9.7", "sssd-ldap.x86_64::1.16.5-10.0.1.el7_9.7", "sssd-proxy.x86_64::1.16.5-10.0.1.el7_9.7", "systemd.x86_64::219-78.0.1.el7_9.3", "systemd-libs.x86_64::219-78.0.1.el7_9.3", "systemd-sysv.x86_64::219-78.0.1.el7_9.3", "unzi  p.x86_64::6.0-21.el7" ]
}

3. Note the kernel before the update.

uname -r
4.1.12-124.47.3.el7uek.x86_64

4. Run the pre-update check for the os.

dbcli update-server -c os -p
{
  "jobId" : "9b02cf04-92a2-4299-8cd0-4ce649b962ec",
  "status" : "Created",
  "message" : null,
  "reports" : [ ],
  "createTimestamp" : "September 24, 2021 14:18:46 PM BST",
  "resourceList" : [ ],
  "description" : "OS Patching Prechecks",
  "updatedTime" : "September 24, 2021 14:18:47 PM BST",
  "percentageProgress" : "0%",
  "cause" : null,
  "action" : null
}

Check if pre-udpate check is successful.

dbcli describe-job -i "9b02cf04-92a2-4299-8cd0-4ce649b962ec"

Job details
----------------------------------------------------------------
                     ID:  9b02cf04-92a2-4299-8cd0-4ce649b962ec
            Description:  OS Patching Prechecks
                 Status:  Success
                Created:  September 24, 2021 2:18:46 PM BST
               Progress:  100%
                Message:

Task Name                                                                Start Time                          End Time                            Status
------------------------------------------------------------------------ ----------------------------------- ----------------------------------- ----------

5. Run the os update.

dbcli update-server -c os
{
  "jobId" : "a7097060-6234-401d-bfd7-1c1fcbb9de85",
  "status" : "Created",
  "message" : null,
  "reports" : [ ],
  "createTimestamp" : "September 24, 2021 15:41:34 PM BST",
  "resourceList" : [ ],
  "description" : "OS Patching",
  "updatedTime" : "September 24, 2021 15:41:34 PM BST",
  "percentageProgress" : "0%",
  "cause" : null,
  "action" : null
}

The first run of the OS update failed with below output..

dbcli describe-job -i "a7097060-6234-401d-bfd7-1c1fcbb9de85"

Job details
----------------------------------------------------------------
                     ID:  a7097060-6234-401d-bfd7-1c1fcbb9de85
            Description:  OS Patching
                 Status:  Failure
                Created:  September 24, 2021 3:41:34 PM BST
               Progress:  78%
                Message:  DCS-10206:Patch bundle conflicts with: Yum Failed to resolve conflict
                  Cause:  Conflict check failed.
                 Action:  Rollback the conflicting patches and retry the operation.

Task Name                                                                Start Time                          End Time                            Status
------------------------------------------------------------------------ ----------------------------------- ----------------------------------- ----------
OS Component Patching                                                    September 24, 2021 3:41:34 PM BST   September 24, 2021 4:22:04 PM BST   Failure
task:TaskSequential_919                                                  September 24, 2021 3:56:45 PM BST   September 24, 2021 4:22:04 PM BST   Failure
Validating OS Patches                                                    September 24, 2021 3:56:45 PM BST   September 24, 2021 4:22:04 PM BST   Failure

After a SR Oracle support confimed that updating is hitting a bug (internal 33403308). After the bug was fixed by Oracle development team ran the command again and OS update was successful.

dbcli update-server -c os
{
  "jobId" : "b1ad604f-7961-4854-a05d-9e43958312b7",
  "status" : "Created",
  "message" : null,
  "reports" : [ ],
  "createTimestamp" : "September 29, 2021 09:32:50 AM BST",
  "resourceList" : [ ],
  "description" : "OS Patching",
  "updatedTime" : "September 29, 2021 09:32:51 AM BST",
  "percentageProgress" : "0%",
  "cause" : null,
  "action" : null
}

dbcli describe-job -i "b1ad604f-7961-4854-a05d-9e43958312b7"

Job details
----------------------------------------------------------------
                     ID:  b1ad604f-7961-4854-a05d-9e43958312b7
            Description:  OS Patching
                 Status:  Success
                Created:  September 29, 2021 9:32:50 AM BST
               Progress:  100%
                Message:

Task Name                                                                Start Time                          End Time                            Status
------------------------------------------------------------------------ ----------------------------------- ----------------------------------- ----------

The issue seems to have been fixed permanently as subsequent OS patching of other DB systems didn't have any issue.

6. Reboot the node and verify the kernel is updated.

uname -r
4.1.12-124.53.5.el7uek.x86_

Related Post
Updating the OS and Patching OCI PaaS DB Using DBCLI

Using OCI Bastion for Accessing EM Database Express

OCI bastion allows a restricted and time-limited way to access private endpoints. This could be used for accessing EM database express of DBCS VM DBs. Since most of the cases database would reside in a private subnet, the bastion service provides a convenient way to accessing these services with private endpoints. Only downside is that maximum time to live (TTL) for a bastion session is 3 hours. So this wouldn't be good for 24/7 monitoring (unless creating a new session every 3 hours is not a hazzel). This post shows the steps for creating a bastion session and accessing the EM database express using it.
First up some details about the DBCS VM DB setup. The database system resides in a private subnet.

If not already done, enable EM Express for the database. For more info on this refer 2453454.1. In this setup the EM express runs on port 5500.
Access bastion service from the OCI console (found under Identity and security). Give a bastion a name and select the same VCN and private subnet where the databsae resides. These sections shown in red. In addition to above provide a list of IPs or hostname that will access the bastion session. In this case a single IP is given (public IP for the test windows pc shown by whatsmyip). This section is shown in blue.

Once the bastion is created make a note of its private endpoint.

Add an ingress rule to the security list associated with the private subnet (where the database resides) using the bastion endpoint as source. This step is not needed if an exiting rule already allows this traffic.

Make a note of the private IP of the database node.

Next create a bastion session by selecting port forwarding as the session type. As the IP address specify the private IP of the database node. Specify the port on which EM express runs, in this case 5500. Finally provide a public key of a ssh key pair. This doesn't have to be the same key used for the database. This key is used only for the bastion session and has no relevence for the database.

Click the menau at the end of the bastion session (three dots at the end) and select copy ssh command. This will copy the ssh command to needed to create the tunnel to the clipboard.

Replace the placeholder values with actual values. Placeholder values include the private key file and the local port. In this case the local port is also set to 5500. If running on windows the power shell could be used to execute the ssh to create the port forwarding ssh tunnel.

Once the ssh tunnel is created access the EM express from the PC browser using localhost as the server.

Getting DB Passwords from Vault Secrets for OKE Deployments

OCI allows storing of DB passwords as secrets in the vault. These secrets could be retreived using various SDKs, CLI and etc. This post shows how DB password could be retreived from a vault for JDBC Connection pools when a java application is deployed in OKE.
1. In order to retreivew the secrets from vault the user making the request must be authenticated. Instance principal is used to avoid using a password based authentication for this. OCI allows dynamic group be created based compartment, instance id, tag and tag value. As a first step create a dynamic group specifying the compartment where OKE worker node resides and some qualifying tags. The dynamic group is called "test dynamic group".

Compartment is used instead of instance ID in the dynamic group creation. This is due the fact that new worker nodes could be created and old ones destroyed as part of the life cycle of the OKE cluster. Tag values have been used to further reduce the number of instances that qualify for the dynamic group. All worker nodes would have "oke" as the created-by tag value. So this tag could be used to distinguish between OKE cluster service created instances vs other compute instnaces. Further reduction could be made based on project, enviornment and etc.
2. Create the secrets in the vault. Secrets could be created with a prefix which would allow writing of policy capturing only the secrets with the specified prefix text. Below two secrets have been created both with prefix "acme_test_prod".

3. Write a policy allowing dynamic group to access the secret bundles. Use the vault id and prefix of the secret to restrict the dynamic group to specific set of secrets and vaults. Below policy would allow test_dynamic_group to get all the secret bundles with names begining with "acme_test_prod" in the specified vault id.

Policy is written for secret bundles as that's what the java API expect. If this is done for OCI CLI then policy could be written for secrets instead of secret bundles. Java API access fails when policy only allow access to secrets instead of secret bundles.



4. Final step set is to write the java code that would be deployed as part of the application into OKE cluster. Download the java SDK from the link here. Below is an example java code that uses instance principal provider to create a secrets client that could be used to retreive the secrets from the vault.

final InstancePrincipalsAuthenticationDetailsProvider provider;
        try {
            provider = InstancePrincipalsAuthenticationDetailsProvider.builder().build();
        } catch (Exception e) {
            
            throw e;
        }
    
        SecretsClient secretsDpClient  = new SecretsClient(provider);
                
        GetSecretBundleByNameResponse getSecretBundleByNameResponse = secretsDpClient.getSecretBundleByName(GetSecretBundleByNameRequest.builder()
        .secretName("acme_test_prod_schema1").vaultId("ocid1.vault.oc1.vault id here...").build());
        
        Base64SecretBundleContentDetails details = (Base64SecretBundleContentDetails) getSecretBundleByNameResponse.getSecretBundle().getSecretBundleContent();
        byte[] content = Base64.getDecoder().decode(details.getContent());
        //System.out.println("Password : "new String(content));
        
        PoolDataSource ds = PoolDataSourceFactory.getPoolDataSource();
        ds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource");
        ds.setURL("jdbc:oracle:thin:@test");
        ds.setUser("asanga");
        ds.setPassword(new String(content));

Accessing OCI Bucket Using Instance Principal

This post shows how to access a OCI bucket using instance principal. Being able to access a bucket based on instance pricipal is useful as it eliminate the need for sharing passwords. Access to OCI storage buckets may be needed for example when importing a data dump into ATP. With instance princiapl a compute instance could be designated as the uploader of the dump files to bucket which could be imported into ATP later.
1. If not already done create a storage bucket.

2. Have a compute instance that would be used to create the instance principal

3. If the compute instance is in a private subnet then create a service gateway and have a rourting rule to sending service related traffic through it.

4. Create a dynamic group using the compute instance's ID as the value to match.

5. Creaet a policy allowing the dynamic group to read the bucket and manage the objects in the bucket.

6. Install OCI client. This only needs to be installed. No need to configure it. If the compute instance is OEL then this would be done via yum.

7. To check if the instance principal works and bucket is accessible, set the OCI_CLI_AUTH=instance_principal and run a list command against tbe bucket using oci cli. Specify the namespace of the OCI tenancy after -ns (omitted in screenshow below).

Output above shows the content of the bucket. It contain just one file called asanga.dmp.
Another way to specify the authentication in the oci cli is to use the --auth. This eliminate the need to set an environment variable.