Wait…what?
The dark side of the force, the dark side of the moon. I’m not too much into that, I’m not a Star Wars or Pink Floyd fan at all. But I need to accept and recognize that the fact that they used the term dark in one of their most iconic and/or relevant moments, was such a great idea and success at the same time. We all remember Darth Vader telling Luke to come to the dark side of the force (or something like that). And when someone wants to sound interested in music, it is quite common to hear things like: “The best album composed by Floyd was The Dark side of the Moon. They were such a genius”. And well, Star Wars and Pink Floyd indeed influenced pop culture in such a way that they remain valid to these days. I am a big fan of Japanese streetwear and one of my favorite designers is 順 高橋 (Jun Takahashi) who released 2017 a set of t-shirts, and crewnecks inspired by the already mentioned best album of Pink Floyd.
Well, that was not a very orthodox way to start a technology article related to MuleSoft, Netfoundry, and Oracle Cloud. But I can say that the term Dark Service is just as appealing as the Dark side of the moon, or the Dark side of the force. And that’s what I am going to try to do in this article.
The first thing to keep in mind and to recognize is the following:
Gartner was so right on this. We are living it. Our APIs are constantly being attacked, we must do a better job in this regard. But at the same time, since one of the most common use cases for APIs is to expose them to the external world with the idea that developers from other organizations can use them to build their applications, then it is unavoidable to make them public and to allow them to be accessed from the internet, with all the consequences that this implies.
There are different options to apply security policies to our APIs. For example:
• To authenticate the consumer with a username and password
• To make the consumer first obtain an access token, with an OAUTH 2.0 dance
• Mutual Authentication
• In the SOAP world, incorporating WS-Security
• Digital signatures
• Etcétera
And all those mechanisms are valid, but we still need to avoid attackers trying to cause a DoS (Denial-of-service), as well as try to fuzz the requests; and/or try to avoid them skipping rate-limiting mechanisms we have in place. We, also, must be sure about the validity of the identities consuming our APIs.
We need to make them invisible to the attackers to avoid most of the things I am referring to. Invisible? Yes, you’ve read it well.
But how can I make them invisible but at the same time reachable from the internet and consumable by developers? That can be quite a challenge, and a non-sense at the same time.
To continue with the ideas that I’ve shared at the beginning of this article, I can also mention that one of my favorite music bands is OMD (Orchestral Manoeuvres in the Dark). They had several hits in their career, such as Secret, Tesla Girls, Electricity, etc. And just as OMD used to make those Orchestral Manoeuvres in the Dark, we need to make something similar for our APIs if we want to turn them into the dark side of the cloud.
Dark services can be accessed through a public environment (internet) but just for the consumers we want, and for the rest, they will remain invisible. But we are not going to use VPNs or whitelisting in our Firewall. We are not going to open new ports into our firewall, nor use a Reverse-Proxy, none of that. All our resources are going to remain private.
This means that our APIs are not going to be exposed to the internet, they are going to be sitting privately. But with Netfoundry.io we will let external organizations use them but in a very highly secured way. Our public APIs will be turned into dark services: reachable for valid consumers, unreachable for the rest.
High-level diagram showing the different pieces involved in our Dark Services intentions
The previous diagram is very high level but is good enough to explain our objective. Let’s explain it a little bit deeper:
What do we need to make this possible?
Let’s do it!
I have created a new VCN, which is divided into the following subnets:
We have two private subnets and one public subnet. The public subnet is not going to be used at all. The two private ones:
We are going to create an Edge Router with this information:
Once you click on the Create button, you will see this:
Download the key, since you will use it during the provision of the Edge Router at OCI. We will provision it through the Market Place. Let’s go for it.
Let’s head to the OCI Marketplace:
A search for Netfoundry:
Click on the NetFoundry Edge Router and you will land here:
Select your compartment, in my case: darkservices. And click on the checkbox after you read the terms and conditions. And finally, click on Launch Instance.
Then, we selected the following shape:
And the following networking:
And at the Advanced Options section, configure this:
Which is this script:
#!/bin/bash
/opt/netfoundry/router-registration {key}
Where key is the value that you got after creating the Edge Router in the previous steps.
Then just click on the Create button:
After that, the compute instance will start its provisioning process and after a couple of minutes you should see it running:
And at the Netfoundry.io console, the Edge Router should be in green:
Now is the time to provision the Compute Instance to install the MuleSoft Runtime.
In the same compartment we will provision a compute instance with the following characteristics:
And:
And finally:
Be careful selecting the private subnet we’ve created for our MuleSoft Runtime. After a couple of minutes your instance should be up and running:
Since this compute instance is private (IP address 10.0.2.202), and we do not want to use a bastion that we can use to jump into it, we will use OCI cloud shell to connect to it.
Use the cloud shell functionality to connect to private networks and use ssh to connect to the compute instance:
Once you’ve connected to the private subnet, use ssh:
nce at the compute instance, install JDK 11 and the MuleSoft Runtime.
To install the MuleSoft Runtime, download it from here:
https://www.mulesoft.com/lp/dl/anypoint-mule-studio?source=post_page—–20de63cde426——————————–
Upload the zip file into the compute instance. To do that, use the cloud shell functionality to upload it:
The file will be uploaded to the cloud shell terminal, then use the scp command to move it to the compute instance:
I have structured my directories like this:
/u01/mule ← I will unzip the mulesoft runtime there
/u01/java ← I will unzip the JDK 11 file in there
Now is time to register the MuleSoft Runtime into the Anypoint Platform control plane:
Go to Runtime Manager and create a new server:
Type a name for your server and copy the command:
Paste the command under your $MULE_HOME/bin directory, once it finishes you will see this:
At your anypoint platform console, you should see this:
Now is time to start our MuleSoft Runtime:
nohup ./mule > mule.out &
And check that log file the following is written
*********************************************************************
* Started DefaultSchedulerService *
* *
* Resolved configuration values: *
* *
* Pooling strategy: UBER *
* gracefulShutdownTimeout: 15000 ms *
* uber.threadPool.maxSize: 158 *
* uber.threadPool.threadKeepAlive: 30000 ms *
* *
* These can be modified by editing ‘conf/scheduler-pools.conf’ *
**********************************************************************
INFO 2022-12-12 21:19:24,779 [WrapperListener_start_runner] [processor: ; event: ] com.mulesoft.agent.services.healthcheck.AgentHealthCheckService: Initializing HealthCheck service
INFO 2022-12-12 21:19:24,801 [WrapperListener_start_runner] [processor: ; event: ] com.mulesoft.agent.services.artifactvalidator.AgentApplicationValidatorService: Initializing Artifact Validator service
INFO 2022-12-12 21:19:24,802 [WrapperListener_start_runner] [processor: ; event: ] com.mulesoft.agent.services.artifactvalidator.AgentApplicationValidatorService: Total validators loaded: 0
**********************************************************************
* Started domain ‘default’ *
**********************************************************************
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Mule is up and kicking (every 5000ms) +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
**********************************************************************
* – – + DOMAIN + – – * – – + STATUS + – – *
**********************************************************************
* default * DEPLOYED *
*********************************************************************
Let’s deploy a very simple API into our newly created Runtime. Let’s go to the API Manager section in our anypoint platform console and create a new API:
Configure it as follows:
And:
Click on the Next button, and configure it as follows:
Then we will configure the API to point to this implementation:
(We are continuing with the idea of the Dark side of the force that we’ve mentioned in the introduction, and because of that we are using the Star Wars API).
On purpose, we are exposing the API at port 8081 and using HTTP only. Then click on the Next button and finally on the Save & Deploy button.
Now is the time to test it. We will do it directly from the compute instance since the only way to hit the Runtime is from within that subnet:
As you can see we got a valid result.
Alright, we are finally at the point where we wanted to be:
We have an API that is just accessible within a private subnet, but we want to make it accessible from/within the internet, but just to specific consumers. That is what the Netfoundry.io magic brings to the table.
In previous steps, we’ve created an Edge Router which is already registered into my Netfoundry.io console:
Now we need to create a new Service in Netfoundry that we can use to reach our API:
We are telling to Netfoundry that we would like to resolve the name: darkside.api.com through port 80 and route it to our private MuleSoft Runtime IP address which is 10.0.2.202.
Now we just need to create and/or assign it to an AppWAN. I will reuse one that I already had, which is accessible from my laptop:
Our network should look like the following image:
As you can see the red box is inside a completely different network to where I am (mylaptop). Is sitting very privately within an OCI subnet. No one from the internet can reach it.
My edge client now should reflect the configuration:
Is time to test it, let’s do it from my browser:
And the magic is there. I am accessing the private API from my laptop, without having to make public a single resource from OCI. Everything that we provisioned is private: the edge router and the MuleSoft runtime. No inbound ports have been opened to the internet. No reverse-proxies, no nothing.
We have a dark service serving at http://darkside.api.com, being accessed from the internet, but I am the only valid consumer so far. The darkside.api.com name does not even exist on the internet, but I can resolve it thanx to Netfoundry.io.
In summary, we have these couple of compute instances in OCI:
Both of them are private. The first one is where our Netfoundry Edge Router is being deployed, and the second one is our MuleSoft Runtime.
Using the Netfoundry.io overlay network we can expose a Dark Service on the internet to access our MuleSoft APIs, but just specific consumers can reach them. Only the consumers that we want, and/or trusted consumers will reach our APIs. For our API initiatives, this is a great mechanism to expose in a very secure fashion our assets. Think about it. With this, we can avoid attackers on the internet can reach our APIs. We can avoid exposing the endpoint to the internet and therefore make it visible to attackers, they won’t be able to scan open ports, to start fuzzing requests, etc.
Suscríbete ahora para seguir leyendo y obtener acceso al archivo completo.