OCI – Using Open Service Broker within Kubernetes to bind to Autonomous Databases

Kubernetes is a great platform to run microservices, there is no question about it. It has great features like Horizontal Pod Autoscaler and Cluster Autoscaler that make it very easy to scale whole applications depending on current or forecasted load. However with auto-scaling there are a few considerations that we need to keep in mind and one of the most important ones is that containers are ephemeral, which implies that we need to design our applications in such a way that they can scale, without compromising data persistency. There are multiple techniques available to make this possible. A common way to achieve this, is by using Persistent Volumes (PV) and Persistent Volumes Claims (PVC), that hook via the CSI (Container Storage Interface) into external disk volumes. This helps maintain state outside containers, allowing them to scale without compromising the data.

Also, with the constant embrace of Cloud providers to kubernetes, these solutions are quickly also evolving and becoming more sophisticated and easier to use. For example, now days we can extend the use of PVC with Storage Classes, implemented by the different Cloud vendors. This make the whole PV/PVC experience so enjoyable, as these storage classes become responsible to interface into the Cloud vendor IaaS land and create resources that we simply declared, while we keep reading and writing data in persistent disks.

Now, with this constant multi-cloud endorsement with kubernetes, it was a matter of time, until Cloud vendors decided to differentiate themselves by allowing the use of foreign cloud services, as first-class citizens in kubernetes. Just imagine, having the ability to use a PaaS service from “Cloud Vendor A”, seamlessly from within my kubernetes cluster that is running on “Cloud Vendor B”. The piece of magic that makes this possible is called, Open Service Broker (OSB), which is really not magic, but just a bunch of APIs that allow the control plane in kubernetes to interact with Cloud services.

In this blog, I am going to show you how to consume Oracle Cloud Infrastructure (OCI) resources from within kubernetes using the Open Service Broker. Specifically, I am going to let my kubernetes control plane to fully manage an OCI Autonomous Transaction Processing DB (ATP), as if it was a native kubernetes resource… And by the way, I am going to use OKE (Oracle managed Kubernetes), but you could very well use Google/AWS/Azure Kubernetes elsewhere and still consume OCI resources. How cool is that?

Continue reading “OCI – Using Open Service Broker within Kubernetes to bind to Autonomous Databases”

Advertisement

OCI – Oracle Container Engine for Kubernetes (OKE) – Using RBAC with IAM

In a recent blog, I explained how to approve in Kubernetes external certificate signing requests from end users. This way, users can then simply use their private keys to authenticate into Kubernetes API server. Further to this, Role Based Access Control (RBAC) can be put in place to authorise access to resources in kubernetes clusters. This is amazing and provides some level of governance, however there is a caveat, since kubernetes does not hold neither users nor groups, the identities must exist outside the cluster somewhere else. If we create external CSRs with non-existent users and groups, soon it will become very hard to properly manage all the identities, especially if we have to maintain multiple users accessing the cluster. This is yet another area that gets highly simplified when Cloud vendors embrace kubernetes as first class citizens.

In this blog, I am going to show you how to create and manage your identities in OCI IAM and simply, using such identities to access Oracle Container Engine for Kubernetes (OKE) clusters and authorise access to resources.

In a nutshell, this is what I am going to do:

  1. Create a new user/group in OCI IAM
  2. Configure an OCI policy to grant access to my user’s group to access the OKE clusters
  3. Create Roles and Role Bindings (RBAC) in OKE to authorise our user to access OKE resources
  4. Download a kubeconfig set for my new user using token validation
  5. Use kubectl to access only granted resources.

Ok, let’s have fun!!!

Continue reading “OCI – Oracle Container Engine for Kubernetes (OKE) – Using RBAC with IAM”

OCI – Oracle Container Engine for Kubernetes (OKE) – Using Client Certificates and RBAC

Kubernetes has been proven the best way that we have today to run microservices deployments, whether it is via a Serverless approach or by managing your own deployments in the cluster. This has solidified with the strong adoption of Kubernetes by all the major Cloud Vendors, as the strategic way to orchestrate containers and run serverless functions.

However, one of the situations that we need to be mindful, is that kubernetes creates by default a super powerful user that has full access to almost every resource in the cluster (accessible via kubectl or directly though APIs). This is very convenient for most dev & test scenarios, but it is imperative that for production workloads, we limit such power and use Role Base Access Control (RBAC), stable since version 1.8, for fine-grained authorisation access control to kubernetes cluster resources.

For the purpose of this demo, I am assuming some familiarity with Kubernetes and kubectl. I will mainly focus on the Authentication and Authorisation aspects that allow us to use Client certificates to get access to protected resources in a Kubernetes cluster.

In a nutshell this is what I am going to do:

  1. Create and use Client certificates to authenticate into a Kubernetes cluster
  2. Create a Role Base Access Control to fine grain authorise resources in the Kubernetes cluster
  3. Configure kubectl with the new security context, to properly limit access to resources in the Kubernetes cluster.

This is a super simplified visual representation:

Continue reading “OCI – Oracle Container Engine for Kubernetes (OKE) – Using Client Certificates and RBAC”

OCI – Remote Peering 2 Virtual Cloud Networks across different Regions

In a previous blog, I explained how to local peer two Virtual Cloud Networks (VCNs) located in the same Region. In this blog, I am going to show you how you can remote peer two VCNs located in different Regions. You might want to use this approach for High Availability or Disaster Recovery scenarios or simply to interconnect private workloads across multiple regions. In order to remote peering 2 VCNs, we are going to use a new type of Networking Gateway in Oracle Cloud Infrastructure, called Dynamic Routing Gateway (DRG). It is important to mention that the communication between the 2 regions does not route over the Internet, but via a dedicated network pre-established private fast connection/backbone, so the communication is secured and low latency. Just for the record, DRGs are the same type of gateways that you would use to establish connectivity between any other Data centres (e.g. on-premise DC or other Cloud providers, e.g. AWS, MS Azure, GCP), as well as to establish IPsec VPN connections or during a dedicated Fast Connect Private Peering communication, but that would be another blog.

For this demo, we are going to connect workloads between Phoenix and Ashburn. Each region will have its own VCN and within each VCN we are going to deploy a private subnet with 1 Linux VM, used to test the inter-communication across the regions.

For the purpose of this demonstration, I am going to show how to:

  1. Attach and configure DRG to each of your VCNs, located in different regions and establish the remote peering.
  2. Configure 2 private VMs, each in a different VCNs (different AD)
  3. Use public bastion host to connect to 1 of the private VMs and then confirm connectivity into the other private VM (cross-region connectivity).

This is a high-level visual representation:

Ok, let’s have fun!!!

Continue reading “OCI – Remote Peering 2 Virtual Cloud Networks across different Regions”

Enabling REST APIs to consume data from Oracle Autonomous Databases (ADW/ATP)

In a previous blog, I showed how to develop microservices to connect to Autonomous Databases and consume data (read/write) via REST APIs. Although I still highly recommend that approach, the reality is that there is an easier way to do it using Oracle REST Data Services modules that come included with any Oracle Autonomous Database (ADW/ATP).

This way you simply have to:

  1. Configure the API endpoint (Method + URL) that you want to expose as a REST API
  2. Define the underlying SQL statement that will serve to your endpoint (i.e. SELECT, INSERT, UPDATE, DELETE statements or a more complex PL/SQL script)
  3. Define the security mechanism to properly protect your APIs

That’s pretty much it, this should be a very quick, yet powerful alternative to building your own microservices to consume data from Autonomous DBs.

Continue reading “Enabling REST APIs to consume data from Oracle Autonomous Databases (ADW/ATP)”

OCI – Local Peering 2 Virtual Cloud Networks across different Availability Domains in the same region

In a previous blog, I explained how to get started with Oracle Cloud Infrastructure Networking primitives to allow Internet traffic into your Virtual Cloud Network. In this blog, I will show you how to peer 2 different Virtual Cloud Networks (VCNs), using VMs across different Availability Domains (AD) in the same region. For this, we are going to use a new type of OCI Networking Gateway, called Local Peering Gateway (LPG).

In Oracle Cloud Infrastructure, VCN are regional and subnets can be configured as regional resources too. This means that they can span across multiple Availability Domains within the same region (normally 3 ADs per region). For this demo, we are going to provision a private VM in a different Availability Domain (AD), each in a different VCN, so that we can make sure that we can establish connectivity across 2 VMs located in different VCNS and Ads, via the Local Peering

For the purpose of this demonstration, I am going to show how to:

  1. Attach LPG to each of your VCNs in the same region and establish the local peering.
  2. Configure 2 private VMs, each in a different VCNs (different AD)
  3. Use public bastion host to connect to 1 of the private VMs and then confirm connectivity into the other private VM.

This is a high-level visual representation:

Ok, let’s have fun!!!

Continue reading “OCI – Local Peering 2 Virtual Cloud Networks across different Availability Domains in the same region”

Getting started with Oracle Cloud Infrastructure Internet and NAT Gateways

Oracle Cloud Infrastructure makes it easy to allow secured ways to let your compute instances in the Oracle Public Cloud to reach the internet, as well as being reachable from the Internet when needed. There are 2 main types of Networking Gateways that makes this easy to implement:

  • Internet Gateway: This type of gateway is directly attached to your Virtual Cloud Network (VCN) and lets your compute instances, that reside in a public subnet, to reach the Internet and being reachable from the Internet. A classic example of this is a bastion host that needs to be accessed via SSH from outside your VCN and that also needs connectivity to the Internet.
Continue reading “Getting started with Oracle Cloud Infrastructure Internet and NAT Gateways”

Autoscaling in Oracle Cloud and OKE (Oracle Container Engine) as load generator

I just came across this great article by Ali Mukadam to autoscale OCI instances based on Instance Configuration, Instance Pools and defining auto-scale policies. Finally, using Kubernetes (OKE) to generate load.

Don’t miss out this great read:

https://medium.com/oracledevs/autoscaling-in-oracle-cloud-and-oke-oracle-container-engine-as-load-generator-2e9ccb44b44

Teaching How to Generate Wildcard SSL Certificates for your LBaaS

Security is super important, but also annoying. From a backend developer mindset, all I want is to build great services exposed as APIs that the world can consume with ease. The problem is that in most cases, consumption of my endpoints will be blocked by browsers and other tools/client unless they are exposed as HTTPS with valid SSL certificates.

In this blog, I am going to show you how to use Let’s Encrypt to create your own “Wildcard SSL Certificate” for your existing domain, for example: *.mydomain.com – Then I am going to show you how to assign this certificate to your Oracle LBaaS Listener endpoint.

Continue reading “Teaching How to Generate Wildcard SSL Certificates for your LBaaS”

Teaching How to Get Started with Oracle Container Engine for Kubernetes (OKE)

In a previous blog, I explained how to provision a Kubernetes cluster locally on your laptop (either as a single node with minikube or a multi-node using VirtualBox), as well as remotely in the Oracle Public Cloud IaaS. In this blog, I am going to show you how to get started with Oracle Container Engine for Kubernetes (OKE). OKE is a fully-managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud on Kubernetes.

Continue reading “Teaching How to Get Started with Oracle Container Engine for Kubernetes (OKE)”
%d bloggers like this: