The OCI Security Health Check script has a new home! It’s now available here – https://github.com/oci-landing-zones/oci-cis-landingzone-quickstart/blob/main/README.md
In addition to this, it’s been renamed to the CIS Compliance Script
Running the script from the OCI Cloud Shell is still as simple as ever:
git clone https://github.com/oci-landing-zones/oci-cis-landingzone-quickstart.gitcd oci-cis-landingzone-quickstart/scriptschmod +x standard.sh./standard.sh
A common question I receive from customers is if it’s possible to access their Oracle Fusion Cloud Applications privately, without using the public Internet. This is where OCI comes to the rescue!
The main purpose of this post is to save me time hunting down the official documentation in the future 😆.
It is possible to route Oracle Fusion Cloud Applications traffic privately using either the OCI Site-to-Site VPN service or FastConnect, together with a Transit Routing configuration.
The official documentation covering the configuration, along with some useful background information, can be found at the links below:
Although the diagram below illustrates private access to OCI Object Storage, the same approach applies to Fusion Cloud Applications, because they also reside within the Oracle Services Network (OSN).
My test tenancy for OCI is a bit of a mess and I needed to give it a tidy-up to remove resources that I no longer used – rather than go through every resource individually and delete it, I found a way to automate this using the superb OCI-SuperDelete script.
I needed to delete all of the resources within a specific OCI Compartment. This can all be achieved using a single command with the script!
The easiest way to run this is using OCI Cloud Shell, using the following commands, which do the following:
git clone https://github.com/AnykeyNL/OCI-SuperDelete.gitcd OCI-SuperDeletepython delete.py -dt -c [compartment_OCID]
Here is a short video of me using OCI-SuperDelete.
Here it is after the script has completed (which took less than five minutes).
This is a very powerful (and potentially dangerous tool 🔥), so please be careful when using it!
It includes far more advanced capabilities than I’ve demonstrated here, further details can be found at https://github.com/AnykeyNL/OCI-SuperDelete/blob/master/README.md
Happy tidying! 🧹.
In my lab environment I recently went through the process of configuring identity federation between OCI IAM and Okta using the guidance within the following documentation – SSO With OCI and Okta.
I ran into an issue within Step 4 – Configure Okta when trying to save the configuration in Okta it returned the following error:
“Does not match required pattern”
Helpfully it highlighted the setting that required attention (Subdomain):
After much trial and error it turns out that this needed the subdomain only, in this case “idcs-de611dc73033481c81a2b7ec19f1b1c6” rather than the entire URL that had been obtained https://idcs-de611dc73033481c81a2b7ec19f1b1c6.identity.oraclecloud.com:443. The instructions for this are a little misleading, as they suggest it’s the entire URL.
Once I’d entered the subdomain in the correct format, I could save the settings and move on the the final step…..testing ✅.
A customer asked me if there was a quick way to check the backup configuration for all of the VM instances within their OCI tenancy because they needed to ensure that all Boot Volumes had a Backup Policy applied ✅.
I created a PowerShell script for them (they are primarily a Windows shop) that does just that for them!
This script does the following
Here is the output of the script from my test tenancy, you can clearly see that I’m being naughty here and only have backup policies assigned for 2 of my 6 VM instances ⛔️.
Here is the script in all its glory! Before running it, update CompartmentId with the OCID of the root compartment within the tenancy.
# Get all Compartments$Compartments = Get-OCIIdentityCompartmentsList -CompartmentId "ocid1.tenancy.oc1..aaaaaaaae" -CompartmentIdInSubtree $true -LifecycleState Active# Loop through each Compartment, identify each VM boot volume and output the assigned backup policyForeach ($Compartment in $Compartments) {Write-Host "Compartment Name:" $Compartment.Name -ForegroundColor Green$BootVolumes = Get-OCIBlockstorageBootVolumesList -CompartmentId $Compartment.IdForeach ($BootVolume in $BootVolumes) { Write-Host "-Boot Volume:" $BootVolume.DisplayName $PolicyAssignment = Get-OCIBlockstorageVolumeBackupPolicyAssetAssignment -AssetId ($BootVolume.Id) if ($PolicyAssignment) { $Policy = Get-OCIBlockstorageVolumeBackupPolicy -PolicyId ($PolicyAssignment.PolicyId) Write-Host "--Backup Policy:" $Policy.DisplayName -ForegroundColor Yellow} else { Write-Host "--Backup Policy: NONE" -ForegroundColor Red } }}
The script is also available on GitHub.
If you need a hand using PowerShell with OCI, check out this guide.
This short video demonstrates how to use the OCI Console to backup and restore a Windows VM instance, which is useful for recovering deleted/corrupted files or if a VM instance needs to be recovered to a specific point in time.
This short video demonstrates how to use the OCI Events service to send an e-mail notification when the state of a resource changes, in this particular example I setup an event to send an e-mail when a Boot Volume backup has been deleted.
In this short video, learn how to use the OCI Monitoring Service to generate alerts when the CPU utilisation of a VM instance within OCI exceeds a given value – for example 50%.
Happy monitoring 📉
I needed to test an OCI Alarm I had created that should send an e-mail notification when the average CPU utilisation of a server exceeds 50% over a 15-minute period.
I found a “quick and dirty” way to generate CPU load on Linux using this one simple command:
yes > /dev/null &
This command runs yes (which outputs an endless stream of “y” lines) and redirects all its output to /dev/null (discarding it), with & putting it in the background.
I then ran htop on the instance and I could see that this pegged the CPU at 100%!
After 15 minutes, I received a lovely alert in my inbox:
If you do this, don’t forget to kill the process afterwards using “killall yes”.
A customer of mine recently ran the OCI Security Health Check 👨⚕️, this flagged up the following issue:
Rather than manually clicking through the OCI Console and updating this setting for all Compute Instances (which would have been mind-numbing!) to resolve this, I wrote a PowerShell script that loops through all instances within a tenancy and changes the Instance metadata service so that it only supports Version 2 (rather than V1 and V2), updating the configuration from this:
To this:
Here is the script in all of it’s glory, it can also be found on GitHub. Simply replace TenancyOCID with the OCID of the root compartment in the tenancy and run – this will loop through all compartments, find all Compute Instances and update the setting.
# Get all Compartments$Compartments = Get-OCIIdentityCompartmentsList -CompartmentId TenancyOCID -CompartmentIdInSubtree $true -LifecycleState Active# Loop through all VMs and update the instance metadata service so that it only supports version 2Foreach ($Compartment in $Compartments) {Write-Host "Compartment Name:" $Compartment.Name -ForegroundColor Green$Instances = Get-OCIComputeInstancesList -CompartmentId $Compartment.IdForeach ($Instance in $Instances) { Write-Host "-Instance:" $Instance.DisplayName -ForegroundColor White $Action = Update-OCIComputeInstance -InstanceId $Instance.Id -UpdateInstanceDetails @{InstanceOptions = @{AreLegacyImdsEndpointsDisabled = $true}} }}
If you need a hand using PowerShell with OCI, check out this guide.
That’s all for now!
Brendan's Tech Ramblings 