Deploy Applications on a Private OKE Cluster Using OCI Bastion and GitHub Actions
Learn how to leverage Oracle Cloud Infrastructure Bastion sessions and GitHub Actions effectively for deploying to a private Oracle Container Engine for Kubernetes (OKE) cluster when the need arises due to various factors such as security, compliance, network isolation, and control.
OKE is a fully-managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud.
GitHub Actions is a powerful workflow automation and continuous integration/continuous deployment (CI/CD) platform provided by GitHub. It allows you to define custom workflows using YAML syntax, which can be triggered by various events such as code pushes, pull requests, or scheduled tasks.
This reference architecture explores the utilization of OCI Bastion sessions and GitHub Actions to deploy to a private OKE cluster.
Architecture
This reference architecture showcases the integration of an OCI Bastion and GitHub Actions to facilitate deployments to a private OKE cluster.
The private OKE cluster is inaccessible from external networks. To access
the K8s API private endpoint, an SSH port-forwarding OCI Bastion session is established. This setup enables the execution of kubectl
commands to perform various deployment operations within the cluster.
When code is pushed to the repository, the GitHub Actions workflow is automatically triggered. During the workflow run, the OCI Bastion session is created and utilized to connect to the private K8s API endpoint for executing deployment actions.
Upon completion of the workflow, the OCI Bastion session is deleted. This approach ensures a highly secure and efficient deployment process. Additionally, this workflow serves as a framework for executing continuous integration tasks and can be further tailored to align with your specific development processes and requirements.
The following diagram illustrates this reference architecture.
oke-bastion-deployment-diagram-oracle.zip
Before you begin
- Provision an OKE cluster with the Kubernetes API endpoint and worker
nodes configured in a private subnet.
Note:
The private Kubernetes API endpoint will be utilized for establishing the OCI Bastion port-forwarding session. - Set the created OCI Bastion service to have the OKE VCN as the target VCN and the OKE node subnet as the target subnet.
- Set the required IAM service policy.
Note:
See Explore More for links to the Policy Configuration for Cluster Creation and Deployment for setting up necessary IAM policies.
The architecture has the following components:
- Tenancy
A tenancy is a secure and isolated partition that Oracle sets up within Oracle Cloud when you sign up for Oracle Cloud Infrastructure. You can create, organize, and administer your resources in Oracle Cloud within your tenancy. A tenancy is synonymous with a company or organization. Usually, a company will have a single tenancy and reflect its organizational structure within that tenancy. A single tenancy is usually associated with a single subscription, and a single subscription usually only has one tenancy.
- Region
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Compartment
Compartments are cross-region logical partitions within an Oracle Cloud Infrastructure tenancy. Use compartments to organize your resources in Oracle Cloud, control access to the resources, and set usage quotas. To control access to the resources in a given compartment, you define policies that specify who can access the resources and what actions they can perform.
- Availability domains
Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.
- Fault domains
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.
- Virtual cloud network (VCN) and subnets
A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- Load balancer
The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end.
- Security list
For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.
- Network address translation (NAT) gateway
A NAT gateway enables private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections.
- Service gateway
The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.
- Cloud Guard
You can use Oracle Cloud Guard to monitor and maintain the security of your resources in Oracle Cloud Infrastructure. Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When any misconfiguration or insecure activity is detected, Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.
- Security zone
Security zones ensure Oracle's security best practices from the start by enforcing policies such as encrypting data and preventing public access to networks for an entire compartment. A security zone is associated with a compartment of the same name and includes security zone policies or a "recipe" that applies to the compartment and its sub-compartments. You can't add or move a standard compartment to a security zone compartment.
- Container Engine for Kubernetes
Oracle Cloud Infrastructure Container Engine for Kubernetes is a fully managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud. You specify the compute resources that your applications require, and Container Engine for Kubernetes provisions them on Oracle Cloud Infrastructure in an existing tenancy. Container Engine for Kubernetes uses Kubernetes to automate the deployment, scaling, and management of containerized applications across clusters of hosts.
- Bastion service
Oracle Cloud Infrastructure Bastion provides restricted and time-limited secure access to resources that don't have public endpoints and that require strict resource access controls, such as bare metal and virtual machines, Oracle MySQL Database Service, Autonomous Transaction Processing (ATP), Oracle Container Engine for Kubernetes (OKE), and any other resource that allows Secure Shell Protocol (SSH) access. With Oracle Cloud Infrastructure Bastion service, you can enable access to private hosts without deploying and maintaining a jump host. In addition, you gain improved security posture with identity-based permissions and a centralized, audited, and time-bound SSH session. Oracle Cloud Infrastructure Bastion removes the need for a public IP for bastion access, eliminating the hassle and potential attack surface when providing remote access.
Recommendations
- VCN
When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.
Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.
After you create a VCN, you can change, add, and remove its CIDR blocks.
When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.
- Cloud Guard
Clone and customize the default recipes provided by Oracle to create custom detector and responder recipes. These recipes enable you to specify what type of security violations generate a warning and what actions are allowed to be performed on them. For example, you might want to detect Object Storage buckets that have visibility set to public.
Apply Cloud Guard at the tenancy level to cover the broadest scope and to reduce the administrative burden of maintaining multiple configurations.
You can also use the Managed List feature to apply certain configurations to detectors.
- Bastion
OCI Bastion let authorized users connect from specific IP addresses to target resources using Secure Shell (SSH) sessions. Please make sure only authorized users have access to create Bastion services and sessions. The access to Bastion should be given only to authorized users.
- Container Engine for Kubernetes (OKE)
Please make sure the necessary IAM policies are created and only authorized users have access to cluster resources. Additional monitoring and logging should be enabled to improve the security posture.
Considerations
Consider the following points when deploying this reference architecture.
- OKE scalability
You can scale out your application by updating the number of worker nodes in the Kubernetes cluster, depending on the load. Similarly, you can scale in by reducing the number of worker nodes in the cluster. When you create a service on the Kubernetes cluster, you can create a load balancer to distribute service traffic among the nodes assigned to that service.
- Application availability
Fault domains provide the best resilience within a single availability domain. You can also deploy instances or nodes that perform the same tasks in multiple availability domains. This design removes a single point of failure by introducing redundancy.
- Security
Use policies that restrict who can access which OCI resources and how they can access them.
OKE is integrated with Oracle Cloud Infrastructure Identity and Access Management (IAM). IAM provides easy authentication with native OCI identity functionality.
Deploy
The GitHub Actions workflow code is available in GitHub.
- Go to GitHub.
- Clone or download the repository to your local computer.
- Follow the instructions in the
READMEdocument.