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.Continue reading “Calling OCI APIs from Postman”
Oracle recently introduced a Web Application Firewall (WAF) to further enhance and secure Oracle Cloud Infrastructure offerings. The Oracle Cloud Infrastructure WAF is based on Oracle Zenedge and Oracle Dyn technologies. It inspects all traffic destined to your web application origin and identifies and blocks all malicious traffic. The WAF offers the following tools, which can be used on any website, regardless of where it is being hosted:
- Origin management
- Bot management
- Access control
- Over 250 robust protection rules that include the OWASP rulesets to protect against SQL injection, cross-site scripting, HTML injection, and more
In this post, I configure a set of access control WAF policies to a website. Access control defines explicit actions for requests that meet conditions based on URI, request headers, client IP address, or countries and regions.
You probably heard that Oracle Autonomous Database (ADB) leverages machine learning to automate with traditional infrastructure related database administration tasks such as security, backups and patching.
No matter how well designed your database infrastructure is, performance and issues relating application or external components which make up the application ecosystem can still have an impact on end user response time or availability. Continue reading “Why Would you Monitor an Autonomous Database?”
In my early experiences with docker, I successfully containerised a few simple Node.js applications as per some of my older blog posts (refer Exploring GitHub, DockerHub and OCCS and the MedRec Hands -On Labs section). As is often the case in the modern IT landscape some software (eg OCCS) falls out of favour as more industry support rallies around new capabilities such as Kubernetes. Oracle has thrown its support behind Kubernetes and has brought to market a capability called Oracle Container Engine for Kubernetes (OKE). OKE can be described as, ” A developer friendly, container-native, and enterprise-ready managed Kubernetes service for running highly available clusters with the control, security, and predictable performance of Oracle’s Cloud Infrastructure.” A benefit of leveraging this capability is you don’t have to install, configure and patch the Kubernetes environment you leave that to Oracle which allows you to focus on using the Kubernetes capabilities to deploy and run your container native applications. Essentially, with OKE you get the latest Kubernetes updates which helps you remain compatible with the CNCF ecosystem without the management and administrative overhead. OKE is integrated with your Oracle Cloud Infrastructure tenancy, and the good news is that Oracle doesn’t charge for OKE, you simply pay for the infrastructure you use for worker nodes and any storage requirements that you need to support your containerised application deployments.
In addition to OKE, Oracle also provides a private registry known as Oracle Cloud Infrastructure Registry (OCIR) for your container images. OCIR is, “a highly available private container registry service for storing and sharing container images within the same regions as the deployments. An integrated, performant platform offering, where users can store their container images easily. Access to push and pull images with the Docker CLI, or images can be pulled directly into a Kubernetes deployment”. You can use Oracle Cloud Infrastructure Registry as a private Docker registry for internal use, pushing and pulling Docker images to and from the Registry using the Docker V2 API and the standard Docker command line interface (CLI). You can also use Oracle Cloud Infrastructure Registry as a public Docker registry, enabling any user with internet access and knowledge of the appropriate URL to pull images from public repositories in Oracle Cloud Infrastructure Registry. In each region that is enabled for your tenancy, you can create up to 500 repositories in Oracle Cloud Infrastructure Registry. Each repository can hold up to 500 images. In this post I have recorded the steps to interact with OCIR.
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.Continue reading “Oracle Cloud Infrastructure OCI Gen-2 Cloud Security – Part II (Identity and Access Management)”
Previously, I have discussed Oracle’s overall information security portfolio in blog entry – Oracle Information Security – Where it begins, Where it ends. It was pertaining to information security in Oracle Cloud Infrastructure – Classic and On-Premises suite of products including Identity and Access Management and Database Security.
In a series of five blog posts, I am going to cover the security concepts in Oracle Cloud Infrastructure (aka OCI or Oracle Gen-2 Cloud). The Oracle Cloud Infrastructure (OCI) is a trusted enterprise cloud platform that offers customers deep control with unmatched security. It provides Oracle customers with effective and manageable security to confidently run their mission-critical workloads and store their data.Continue reading “Oracle Cloud Infrastructure OCI Gen-2 Cloud Security – Part I”