Jeff Simpson and Josh Tatum – Oracle Demo: Cross Domain DevSecOps with GitLab and Oracle Cloud

The Oracle National Security team is proud to provide an introduction to low side to high side Deb. We will be utilizing Oracle's Gen 2 cloud infrastructure and GitLab's DevSecOps pipeline process software. My name is Jeff Simpson and I'll be hosting and our engineer running the demo is Josh Tatum.

G. and has extensive experience in deficit jobs and iterative development across multiple security domains. Josh has been working closely with some of the nation's most sensitive intelligence agencies and consults widely with the US military on their next generation cloud based development processes.

For this demo to make some sense, we should give some background on the answers. Firstly, I'd like to give you an introduction to Oracle's national security regions known as answers here. S.

K. These government regions will cover not only data and operations of the secret classification level, but workloads above top secret as well. The idea is that you can develop your application in a commercial region or other protected government region and then push those development artifacts to the classified regions cleanly and efficiently.

Here is a quick look at the answers attributes at a glance, Oracle has comprehensive handling of classified facilities, connectivity, personnel, service parity and last but certainly not least, compliance. We have a couple of upfront disclosures and assumptions, all of the capabilities you were about to see are hosted on Oracle's cloud because we cannot show you our classified regions. This demo was hosted and our commercial cloud region simulating a low side and high side network, utilizing our unique secure network isolation technology.

We also assume that you have a general working knowledge of the dev SEC process. So what are we going to show you? Our focus today is to look specifically at how a combination of Oracle Cloud and GitLab can facilitate load high iterative development.

The demo will follow the flow shown here. First, we take a look at the overall environment for the demo. Then Josh will provide a look at a sample application development environment and GitLab on the simulated low side network.

After making some changes to the code, GitLab will build, deploy and test the sample application to our Oracle Kubernetes environment. The build process creates docker containers that are deployed into Oracle's container engine for companies otherwise known as OKE. To note OKE is a free service on the Oracle Cloud.

Once the application is built and tested, we will demonstrate how the source artifacts are moved from the low side to the high side. After the move, a new build, deploy and test cycle will occur on the high side network. Then we will conclude with the ramp up and review of the overall process.

The following diagram depicts the environment we will be using for this demonstration on the left. There is the unclassified or lesser classified environment. This is where your main line development will occur as your development and testing proceeds will likely want to automate the push of the source code from the low side to the high side.

Once the updated source makes it to the high side and automated build, deploy and test will occur. The frequency of this cross, the main transfer is up to your project. Please note that all of this is resident within the unclassified Oracle Cloud for this demo, the cross.

The main tool is being simulated for the purposes of this demo. However, when moving from one secure network to another, technology such as the guards and data diodes can be utilized to facilitate transfer between two ergative networks. Now I'll hand it over to Josh Hatam, who'll dive right into the demo.

Thanks, Jeff. Hello, everyone. My name is Josh Tatum and welcome to our demo of Cross Domain DevSecOps with GitLab and Oracle Cloud.

Right here is our low side GitLab environment, and this is running on our Oracle Cloud compute service, which I will quickly demonstrate. So if we go into our Oracle Cloud console and click on compute and select our low side compartment, we can see our compute instance that GitLab is running on. Here's our final repository.

We have our CI yaml will file that details our pipeline here, we currently have four jobs set up in our pipeline. We have our database configuration file that establishes a connection to a database hosted on Oracle database cloud service. And we have our note, JS, file that is going to build out our application.

Here we can see our recent commits. And here we can see our list of pipelines. This is a history of you where all of our past failed and blocked pipelines are listed.

I. YAML file. Now this pipeline has already been passed, but if this was just now being processed, then I would have to approve this before any final changes were pushed to the application.

And I would do that by selecting the approved job and sending my confirmation. We have set up a scan job in the pipeline to pick up on vulnerabilities and automatically block updates from being pushed to the application. There was anything that was picked up in the scan process that needed fixing, such as potential vulnerabilities, that I would see that here.

So I can see that I need to make changes to my code to fix this, I go back to my repository, commit the changes and then start a new pipeline that I would have to approve. Once the process is approved, then the changes are deployed to an application that is running on a cluster using Oracle's Carbonetti engine, and let me show you how Oracle could Bernardes engine works because it's very easy to use. To create a cluster, we hover over developer services and select Carbonetti clusters.

Now, Oracle, Carbonetti Engine or Occy for short, makes the process of deploying a Cuban Nettie's cluster really simple. Here we can choose either quick create or custom create to make a cluster if you use, quick create and you can see here that Occy will automatically deploy your networking gateways cluster and all the worker nodes for you. So here you can specify further information, then review the resources that it will create and then click create cluster.

Now, I've already created a cluster so we can take a quick look at that. We have our cluster details here and we can view the performance monitoring information at the bottom of the page. We can access our node pools from here and diving in further, we can also see our worker nodes.

Now, to move this environment to the high side, we need to create an export file. Now, there are two different methods of doing this, the first method is by using the guey to do that, we can navigate to the general tab under settings and scroll down until you reach the export section. From here, you can download the export file.

The other method is by using the jet lab APIs, which can be used to direct the export file to a storage repository such as Oracle Cloud Object Storage, you can then download the file from here. Once we have that file, we can export this project from the low side to the high side. Hi, Jeff Simpson here again, I want to provide a little more detail on how the transfer of the development assets works between our simulated secure networks in this demo.

First, I'd like to note that the specific method for moving the Gitlab artifacts will depend on your specific environment. The graphic here shows the basic flow from the low side to the high side. The process we were using in the demo is a manually initiated push of artifacts from one network to another, low to high, where networks are fully disconnected through an air gap.

Traditional methods for moving the data between security enclaves would apply. And you may have other steps not shown here. However, you can continue using the lab tools and pipelines in the classified environment.

In either case, developers can automate the process with a combination of jet lab pipelines. Simple scripting actions cloud native oracle tools such as serverless functions, interactive commands and the graphical user interfaces from Jet Lab in Oracle. Here's a quick look at the actual commands we used when they manually initiated process to move the artifacts from the low side to the high side.

After exporting the file with the jet lab user interface, or API, and transferring artifacts to the high side cloud. We first used the Oracle Clouds command line interface to retrieve the G-suit file from cloud storage. Then we use a kernel command with a jet lab API to initiate the import and to confirm its successful completion.

In this case, we show how the import can create a project with a new name. In this case, it's M store Dashti. For our top secret environment.

We can then add to specific environment settings and GitLab such as keys and database connect strings that can be used for the high side containers and Carbonetti cluster. Now let's get back to Josh tatum. We are now in the high side environment where we have successfully imported our project from the low side.

We can see that our files have successfully transferred over with some new additions that we have added to the repository. Let's inspect our pipelines. Here we can see that our pipelines have moved over successfully.

We can also create new pipelines from here. And if we dive into these pipelines, we can see that the jobs from the low side have been exported here as well. If we go back to the repository and click on Commit, we will see that the commit history from the low side has also been exported.

Lastly, we can confirm that our app has been deployed on the high side by connecting to our deployment cluster, using the Carbonetti dashboard. We can see here that the cluster has been provisioned on the high side and that the app is running properly. From here, it's possible to further enhance our environment by changing our database config file to connect to an Oracle autonomist database, which is a much more powerful data platform.

And here, I'll show you what Oracle Autonomist database looks like. So from the main page, we select Autonomist Database warehouse. To create an autonomous database, we simply click the create button, fill out the form and then wait a few minutes for the database to launch.

I've already created an autonomous database, so let's explore that. Oracle Autonomous Database is a database that automatically patches itself, tunes itself, secures itself, scales itself and even backs itself up, which is fantastic for production workloads. If we want to connect to this database, we can download the wallet by clicking on database connection.

Autonomous database also has some powerful preinstalled tools that we can use in the service console. Under development, we have Oracle Apex, which is a low code environment for creating applications that are directly integrated with our database. We also have SQL Developer Web and we have built in machine learning notebooks.

I'll quickly demonstrate APACS. Within Apex, we can create applications for this database with little to zero code by using the create wizard. I'll go ahead and make a new application.

Here we can add pages and features to our app. And within each page, we can ingest data straight from the database itself and launch it into production. Once we are done adding the pages we want, we can just click build application and it will launch it for us.

And there we go, we now have an app created straight from the database in a matter of minutes, so that's how autonomous database works in a nutshell. Now, what if we wanted to move this entire environment along with the underlying infrastructure to another location? Well, we could do that with Oracle Resource Manager, which would allow us to rapidly provision this environment using TerraForm Scripps.

To get there from the council, we scroll down to resource manager and click Stack's. Oracle resource manager isn't Oracle Cloud Infrastructure Service that allows you to automate the process of provisioning your infrastructure resources. You can click here to upload your own terraformed scripts and set up your STAC.

I've already built a stack that contains all of the terraformed scripts required to launch this environment rapidly anywhere we want. All of our terraformed stacks can be managed and deployed from here. Over here, we can see our jobs, edit variables, see our work requests and view the state.

Here we can view our state code. We can dive right into the terraform code for each job. Now, I'll click around a bit while I explain this further, one of the primary benefits of using resource manager is that you can have teams collaborate over terraformed configurations and you can secure team access at the compartment level and specify policies on user groups.

You can also define permissions on terraform actions, set up state locking, and it automatically retains all of your state information in persistent storage. And this is fully supported for CLI, SDK and console UI. Using TerraForm Resource Manager helps you install, configure and manage resources through the infrastructure as code model.

And this concludes our demo for today. Thank you for watching, everyone. So here we are at the end.

Let's briefly review what we've covered. We had a look at the environment. We have been using a combination of jet lab tools and the Oracle cloud simulating a low side to high side development process.

Josh took us through the low side development process and how the jet lab tools facilitate the deficit jobs construct. We also took a look at how we would transfer development artifacts from the low side to the high side and a variety of situations, including our simulated networks hosted within the Oracle Cloud. We took a look at all the artifacts on the high side and how GitLab pipelines can facilitate an easy build and test in the high side environment.

And now we're here at the conclusion. Thank you very much for spending some time with us during this demo. We hope you take away a newfound appreciation for the lab tools and the cloud and how they can work together.

Please don't forget to join us here at our virtual booth at the Gitlab Commit conference. We're looking forward to seeing you there.