In the world of cloud computing there are often multiple ways to achieve the same or similar result. In Oracle Cloud Infrastructure (OCI) logs are generated by the platform itself such as audit logs, OCI native services such as the Network Firewall Service, and custom logs from compute instances or your applications. These logs typically live in OCI logging where you can view them, or search them if required.
Collecting and storing logs is useful, however if you want to produce insights then you will need a way to analyse and visualise the log data. OCI Logging Analytics allows you to index, enrich, aggregate, explore, search, analyse, correlate, visualise and monitor all log data from your applications and system infrastructure.
From OCI logging there are two common ways in which logs can be ingested into Logging Analytics. The first is using a Service Connector to send logs to an Object Storage bucket, and an Object Collection Rule to then import the logs into Logging Analytics. The second option uses a Service Connector to send the logs directly to Logging Analytics. Both are valid options however require some consideration before use.
If you are running Oracle E-Business Suite (EBS) application today you will now be able to perform an auto discovery of all related resources in OCI Stack Monitoring. It will collect metrics specific for your EBS resources as well as ability to perform correlation across the EBS application and infrastructure stack as well as enable proactive alerting.
Components that will be auto discovered includes:
Concurrent Processing Node
Today, Stack Monitoring service supports EBS version 12.1 and 12.2 deployments hosted on OCI, On-Premise or Third Party Cloud (eg. AWS, Azure).
In the example, I will show you how you can configure Stack Monitoring for EBS version 12.2.
Oracle Cloud Agent (OCA) – This agent is deployed by default if you provision hosts via the OCI Compute Service. OCA has extensions and plugins which can be used to enable other features native to OCI Compute Services.
Management Agent (OMA) – This agent is a standalone version where you can deploy to hosts or VMs: – That do not have OCA installed on OCI eg. OCI Database Services (eg. Oracle Base VM/BM, ExaCS). – On-Premise – Third Party Cloud (AWS, Azure etc..)
Please see the current O&M support we have for each agent:
Oracle Cloud Agent (OCA)
OCI Compute VM / BM Host
Oracle Management Agent (OMA)
Other VM Host (including on-premise and 3rd party cloud)
OMA Agent Install
In previous post, I have provided steps on how you can install the Oracle Management Agent.
OCA Agent Install
For this post, let me show you how easy it is to enable the O&M services for Oracle Cloud Agent (OCA).
HTTPS is essential as it protects the privacy of our data over the Internet. W3’s 2022 report shows nearly 80% of all websites use HTTPS as their default web protocol, up 6% on the previous year.
Getting started with HTTP/TLS is fairly straightforward. Obtain a CA signed certificate, configure it on your web servers and reverse proxy load balancers and you’re good to go. But how do you ensure your configuration stays up-to-date with current industry standards?
CyberSecurity is an arms race. As hardware and software evolves, so do the tools and techniques created to exploit them. This fierce race largely drives the innovation that we see in the industry today.
How does this relate to TLS? Since the inception of SSLv1 by Netscape in the 90’s there’s been many revisions, SSLv2, SSLv3, TLSv1.1, TLSv1.2 with the current version being TLSv1.3. TLSv1.1 was deprecated in 2021, with new versions being released approximately every 5 years. Given the rate at which exploits are discovered these release cycles will also need to keep pace.
For organisations this poses a number of interesting challenges because you can only control what TLS versions you support. Also if your website or API is public then it’s likely you have no control over the connecting client, or which TLS versions they’re able to use.
There is plenty of information out there about connecting from an on-premises network to OCI. But if you want to see a step-by step-procedure that configures to completion an actual VPN you will have a hard time finding it. And rather than writing about it, this time I will actually show it.
This link will take you to the list of OCI’s verified CPE (Customer Premises Equipment) devices. If your On-Premises CPE is in this list then the VPN configuration should be very easy. In my case, the router I used is not in the list. It is a SOHO (Small Office-Home Office) type of router. For this configuration the on-premises network is my Home-Office LAN. For routers not on the list, there is an option called “other”. OCI offers a lists of supported configuration parameters for VPN connections that you can use for “other” types of routers. Here is the link to these parameter. And I explain them in the video. I hope that you find it useful:
Oracle’s Cloud Infrastructure has been designed in an API-first manner, which is awesome for all sorts of infrastructure automation tasks. It also implements an interesting API security model, in which all requests must be signed using a private key, associated with a public key which has already been configured in OCI (here, the developers are showing their infrastructure roots, as this echoes how SSH Auth is normally handled). The documentation of this model provides sample code in a number of languages, which is perfect if you are writing automation scripts, but is a little inflexible for ad-hoc testing. Typically I much prefer to use a rich graphical REST client, such a Postman, so that I can easily tweak my parameters and try out different types of calls before I write any code. Unfortunately while Postman is well equipped for Basic and Token based Auth, HTTP-Signature is not natively implemented, and rather than abandon Postman for a new tool, I set out to implement it using Postman’s powerful scripting capabilities. In this blog post I provide the result of this, which is a downloadable collection which provides all of the required scripts, and discuss the approach used.
In my previous blog posts, I have discussed the generic security concepts and Identity and Access Management in OCI. This part of the series discusses OCI Networking Service. Its concepts and best practices for securing networks in OCI.
High-throughput and reliable networking is fundamental to public-cloud infrastructure that delivers compute and storage services at scale. As a result, Oracle has invested significant innovation in Oracle Cloud Infrastructure networking to support requirements of enterprise customers and their workloads. Oracle Cloud Infrastructure regions have been built with a state-of-the-art, non-blocking Clos network that is not over-subscribed and provides customers with a predictable, high-bandwidth, low latency network. The data centers in a region are networked to be highly available and have low-latency connectivity between them.
In this post, I will go into depth on the components that make up the networking layer, and the security rules which can be applied to them.
In my previous blog post Oracle Cloud Infrastructure OCI Gen-2 Cloud Security – Part I , I have discussed the seven pillars of information security upon which Oracle Cloud Infrastructure OCI (Oracle Gen-2 Cloud) is built. The cloud shared security and responsibility model was discussed along with the concepts such as Regions, Availability Domains and Fault Domains. This part discusses the Identity and Access Management for OCI. It provides authentication and authorisation for all the OCI resources and services.
An enterprise can use single tenancy shared by various business units, teams, and individuals while maintaining the necessary security, isolation, and governance, and this post will go into the concepts involved in this.