This is a guest IAM blog written by OCI Security expert Paul Toal.
Oracle Cloud Infrastructure (OCI) comes with its own, enterprise-class Identity and Access Management (IAM) service, which is used to manage users and their permissions within OCI. It can also be used for managing access to resources, applications, and services outside OCI, including on-premises. If you have been using OCI for some time, you may be familiar with Identity Cloud Service (IDCS) and how it was used to layer additional IAM capabilities over the core OCI IAM service. The capabilities from IDCS have now been merged into OCI through the introduction of OCI IAM Identity Domains, meaning IDCS no longer exists as a separate service. There is a great FAQ posted to answer many common questions about this change, including why Oracle has made the change and the benefits of this change.
Oracle has recently undergone the process of automatically migrating all existing OCI customer tenancies from IDCS to identity domains. In this article, we will examine the implications of the migration and the best practices following a tenancy IAM migration.
I’m sure we’ve all experienced it, either as a user, or as a system administrator. You know, that important SSL certificate everyone forgot about so didn’t renew, and now has expired?
When an SSL/TLS certificate expires it can create a number of problems, including:
Users’ web browsers will display warning messages, indicating that the website’s connection is not secure. This can lead to a loss of trust and deter user engagement.
API clients will often refuse to establish a connection if an SSL certificate is not valid potentially disrupting crucial data exchanges and integrations.
Search engines may flag the site as unsafe, leading to a drop in rankings and reduced organic traffic.
Also regularly encountering certificate warnings conditions users to accept future certificate errors, which makes them more likely to accept an SSL certificate warning should they be targeted in a Man In The Middle Attack.
To avoid these issues, it’s important to have enough advance warning that a certificate is going to expire so you can obtain a new one, install, and test it thoroughly.
If you’re already using Domain Validated (DV) certificates, such as those issued by Let’s Encrypt you might want to consider my automated Let’s Encryption Solution. This solution automatically handles the entire certificate lifecycle using serverless functions inside OCI. For those who prefer to bring their own certificates, these can be imported into OCI’s certificate service.
As at June 2023, certificate expiry monitoring in OCI is primarily focused on certificates associated with Load Balancers. To improve monitoring, I’ve developed a serverless solution that examines all certificates expiration dates. The solution emits logs and sends email notifications, also allowing for customisable lead time to align with your organisation’s certificate procurement process. Logs can also be forwarded to your SIEM solution if required.
If you’re running workloads in Oracle Cloud Infrastructure (OCI) then it’s likely you’ll be familiar with Virtual Cloud Network (VCN) resources such as Subnets, Route Tables, Gateways etc. These software defined components allow you to build networks in OCI for you to deploy and run your workloads.
Oracle has documentation that explains VCN access and security features which include things like Security Rules, Security Zones, Local and Network Firewalls, and IAM policies. Security rules are made up of Security Lists and Network Security Groups (NSG’s) and are a foundational element of every VCN and Subnet that you create. They define what traffic is allowed in and out of your subnets and what hosts can talk to one another. When you create a subnet a Security List is automatically created with some default rules:
Default Security List Ingress RulesDefault Security List Egress Rules
When it comes to implementing network access controls, you can use Security Lists, Network Security Groups or both. They are virtual firewall features that control traffic at the packet level. I’ll be covering Network Security Group reviews in a later post as I want to focus on Security Lists, specifically how you can easily review and validate rules to ensure they align with your workload, organisational, security and compliance requirements.
In my previous post I explained how you can use Let’s Encrypt and Oracle Cloud Infrastructure (OCI) serverless functions to obtain a publicly signed SSL certificate, and automatically manage its renewal lifecycle. The solution works as expected; I have a Let’s Encrypt certificate for my website automatically renewing 30 days before expiry. If you haven’t read my previous post I’d recommend taking a look before following the setup outlined below as it covers how the solution works, and some prerequisites.
Having multiple workloads running in various OCI regions I started thinking about a more elegant way to provision certificates across multiple regions. Certificates stored in the certificate service are only available to resources in the same region and would have required a function to be deployed in each region, and for each SSL certificate required.
I’ve since updated the solution to address this requirement. It is now possible to provision certificates across multiple OCI regions using a single OCI Function application. I’ve also taken the opportunity to implement other features such as:
Loading a list of certificates you want to manage from a JSON file stored in Object Storage.
Adding support for wildcard SSL certificates.
Adding support for Subject Alternative Names (SAN) in addition to the CN name.
Adding support for the use of DNS zones and Vaults that reside in different regions to the OCI Function.
Adding support to specify which vault, and region to use for a given certificate ensures that workloads with strict cryptographic key material requirements can still benefit from this solution.
If you’ve already followed the instructions from my previous post, the solution will continue to work as described. The only limitation being that it’ll only work for a single certificate. By following the steps below you can easily upgrade to issuing multiple certificates. If you haven’t set anything up yet that’s also fine as I’ll be covering the full install again here.
Let’s Encrypt made its debut back in late 2015. It is a free Certificate Authority provided by the Internet Security Research Group. The goal was to support the adoption of SSL / TLS to ensure the privacy of information sent over the public Internet. Let’s Encrypt is now serving over 2.5M certificates per day.
If you’re reading this it’s likely you’ve had to deal with SSL certificates before. It’s also likely some of you will have investigated an outage, only to find that an SSL certificate expired somewhere that no one knew about. Certificate discovery, management, and renewal can be time consuming and not much fun.
Cloud providers have made this job easier with the introduction of certificate services that are able to issue public Domain Validation (DV) certificates. Oracle Cloud Infrastructure (OCI) currently allows you to create private Certificate Authorities (CA’s), private Certificates, and private Certificate Authority bundles. Private certificate resources are used to secure communication across a private network, where certificates can be installed and trusted to enable secure communication.
But what about publicly signed certs for users connecting over the Internet? Using a private OCI certificate will result in a “certificate not trusted” error in your web browser; this is where Let’s Encrypt comes in. I’m going to show you how to run a completely automated serverless Let’s Encrypt solution in your OCI tenancy to install and automatically renew certificates that show as trusted in your web browser.
If you’re like me, then working in IT means you also assume Tech Support duties for friends, family, and those distant relatives that only seem to call when they’ve got a problem.
I just clicked on this link, and my computer is doing something weird. I think my PC has a virus, what do I do?
When it’s just a single computer, the answer is simple, contain and validate the rouge software is removed, install an AV solution, change their passwords, enable MFA, and provide some education on what to look out for next time.
But now imagine you’re an organisation building a new application, or are moving applications to the cloud. Are you simply performing a lift-and-shift or are you planning to make use of cloud native services? Where are you going to store your data, specifically user uploaded files? Object Storage was built specifically to solve the challenges of how to store unstructured data in the cloud.
However, there is a catch. If you were previously storing files on a server file system, then it’s likely you were also running an anti-virus / anti-malware solution to identify malicious files. With Object Storage the underlying file system is transparent, so you can’t install AV, yet many compliance requirements still state “Uploaded files must be scanned for viruses and malware”.
I’m sure we can all agree, adopting a cloud strategy is awesome. The opportunities and benefits it affords are many. However cloud governance is an ongoing problem that plagues security, compliance, and management teams, which cloud vendors like Oracle are continually trying to solve.
If you’re reading this, you’ve probably been asked, or heard at least once:
Who has access to what in our environment?
Any Security / Compliance Manager
The answer should be easy and simple. However the reality is likely lots of manual time & work, spreadsheets, and endless clicking in a cloud console. If you’re doing this manually then I agree, it’s time that you could be dedicating to more important tasks.
The challenge in trying to answer these questions:
What users exist and what groups do they belong to?
What does my OCI tenancy compartment structure look like?
What policies have users explicitly created?
What permissions do users have in my tenancy?
Are there any excessive / non-compliant policies & permissions in my tenancy?
is that these complex relationships can’t be easily represented and interpreted in a table-like format. In the OCI ecosystem:
users can be federated with an Identity Provider and can belong to one or many federated, or local IAM groups,
policies can be defined for “any-user” or for a group,
policies are inherited meaning they apply to all sub-compartments from which the policies are applied.
To make things easier I’ve created a solution using Oracle tools and services to simplify the auditing of OCI tenancies and user permissions called “Peek”.
Note: From 22/05/2023 APEX is no longer required as the solution runs entirely inside the container. To run the new container for OCI with IDCS use the following command:
docker run -it --name peek --rm \
--mount type=bind,source=/Full/Path/To/.oci/,target=/root/.oci/,readonly \ -e OCI_PROFILE_NAME=<from your OCI config> \-e OCI_TENANCY_OCID=<from text file> \
-e OCI_IAM_URL=<from text file> \
-e IDCS_URL=<from text file> \
-e IDCS_CLIENT_ID=<from text file> \
-e IDCS_SECRET=<from text file> \-e TOOLTIP_LINE_PX=20 \
-p 4567:4567 \scottfletcher/oci-peek
After the docker container has started, you can access the web interface using the locally mapped port http://localhost:4567. You should see a progress window:
Once the mapping process is complete the visualisation will appear.
Depending on how long your policy statements are, you may wish to adjust TOOLTIP_LINE_PX to a number greater or smaller than 20. If your policy statements overflow the tooltip box then increase this value, or if the box is too big, then you can decrease this value.
If you haven’t run Peek before, please read on as I explain how to create the required credentials and where to obtain the values for the other environment variables. You can skip the APEX steps, as APEX will not be used.
Integration platforms are often required to handle confidential information such as personal details, payment information or other data protected by compliance and regulatory standards such as HIPAA, GDPR, PII and PCI.
Various methods exist to protect data from unauthorized access while data is in transit and at rest. These approaches typically encrypt the entire payload. As a complementary approach Field Level Encryption has an important role to play by ensuring that only appropriately configured clients can read sensitive data fields. This approach also allows clients without the encryption keys to work with the non-sensitive data which would be impossible to do with a fully encrypted payload.
Although Field Level Encryption (FLE) is not natively supported in Oracle Integration (OIC) today, this blog will explore several options that will allow you to implement FLE with OIC. In this blog, I will present these options, discuss some guiding principles and showcase some sample implementations.
This is my 15th #DaysOfArm article that tracks some of the experiences that I’ve had so far. It’s been a little while since I’ve worked on this series however saying that … much of what I’ve been doing didn’t seem different from any other type of environment.
And just to recap from the first post (here) on June 12 2021.
It’s been just over 2 weeks since the launch of Ampere Arm deployed in Oracle Cloud Infrastructure (OCI). Check this article out to learn more (here). And it’s been about one week since I started looking into the new architecture and deployment, since I started provisioning the VM.Standard.A1.Flex Compute Shape on OCI and since I started migrating a specific application that has many different variations to it to test it all out.
This is my next learning where I looked into Let’s Encrypt to create a set of free certificates for Oracle Cloud Infrastructure A1.Flex VM Instances.
In the previous post, I did some work in managing Security Lists to protect the Minecraft Server. To read about that, head (here). Another method of connecting to the Minecraft Server is through a Bastion Host. As part of Oracle Cloud Infrastructure, it is free to create a session through the Bastion Service (service limits do apply). Here’s a brief encounter of getting this up and going.
RedThunder.Blog 