SPS

Etiqueta: Netfoundry

Categorías
Zero Trust

LAOUC Community Tour 2024: El evento de conocimiento de Tecnología Oracle, impulsado por la Comunidad del Grupo de Usuarios: ORAMEX

LAOUC Community Tour 2024 Comunidad de usuarios ORACLE
LAOUC Community Tour 2024 Comunidad de usuarios ORACLE

LAOUC Community Tour 2024: El evento de conocimiento de tecnología Oracle, impulsado por la Comunidad del Grupo de Usuarios: ORAMEX

¿Habías escuchando hablar del LAOUC Community Tour?

Este viernes 02 de agosto se llevará a cabo la edición 2024 del LAOUC Community Tour, en el Anexo de la Facultad de Ingeniería de la Universidad Nacional Autónoma de México.

 

LAOUC Community Tour 2024

Durante este evento, se ofrecerán conferencias en aulas del centro de cómputo, y se cuenta con una agenda clasificada en 4 ejes principales:  APEX, ORACLE DATABASE, CLOUD DEVELOPMENT, DIFFERENT TOPICS.

 

Agenda LAOUC Community Tour 2024

Agenda del LAOUC Community Tour 2024

LAOUC Community Tour es un evento para entusiastas y usuarios de la tecnología ORACLE

Si eres un entusiasta de la tecnología ORACLE, o en tu compañía trabajan con alguna de sus tecnologías y quieres ampliar tu dominio o conocimiento, definitivamente asistir a este evento te permitirá explorar casos de uso, o estrategias basadas en las experiencias de los presentadores. 

13_ORAMEX

Durante años anteriores, este evento ha reunido a más de 300 personas el mismo día. El año pasado, el equipo de ORAMEX, tuvo la oportunidad de realizar este evento en el ORACLE MDC (Centro de Desarrollo de Soluciones en la Nube de Oracle), ubicado en Guadalajara, Jalisco, y fue todo un éxito debido a que tuvimos asistentes de diferentes partes del mundo. Todos con la misma finalidad: ampliar sus conocimientos sobre tecnología ORACLE.

ORACLE MDC

ORACLE MDC, Guadalajara, Jalisco

Además de obtener conocimiento, el LAOUC te permite crear conexiones con otros especialistas en tecnología, por lo que es una gran oportunidad para realizar networking, incluso generar oportunidades de negocio. 

LAOUC Community Tour en ORACLE MDC Guadalajara, Jalisco
LAOUC Community Tour en ORACLE MDC Guadalajara, Jalisco
LAOUC Community Tour en ORACLE MDC Guadalajara, Jalisco
LAOUC Community Tour en ORACLE MDC Guadalajara, Jalisco
LAOUC Community Tour en ORACLE MDC Guadalajara, Jalisco
03_ORAMEX

¡Anímate a ser parte del LAOUC Community Tour 2024!

Asiste junto con tus compañeros de equipo, de la universidad o clientes. Sólo debes registrarte:

¡Regístrate aquí!

Si ya te has registrado, y has calendarizado tu asistencia, te compartimos este vídeo, que te será de ayuda para que puedas llegar sin contratiempos al Anexo de la Facultad de Ingeniería de la UNAM.

¡Te esperamos este 2 de agosto a partir de las 8:00 am! 

Autor

Seleni Vargas

Marketing & Content Manager at SPS
LinkedIn
Categorías
Zero Trust

¿Qué es el Zero Trust Network?

¿Qué es el Zero Trust Network?

¿A qué nos referimos con la «Cero Confianza»?

El Zero Trust Networking (ZTN) es un enfoque de seguridad de redes basado en el principio de que ninguna entidad, ya sea interna o externa a la red, debe ser confiable por defecto. En lugar de asumir que todo dentro del perímetro de la red es seguro, el modelo Zero Trust requiere la verificación constante de todos los usuarios y dispositivos que intentan acceder a los recursos de la red. Este enfoque se opone al modelo tradicional de seguridad, que se basa en proteger el perímetro de la red y confiar implícitamente en todo lo que está dentro.

John Kindervag, senior vice president, cybersecurity strategy, ON2IT Cybersecurity

¿Cómo el Zero Trust Network ayuda a la seguridad de los procesos empresariales?

El Zero Trust Networking mejora la seguridad de los procesos empresariales de varias maneras:

Reducción de la superficie de ataque: Al segmentar la red y aplicar controles de acceso estrictos, ZTN minimiza las oportunidades para que los atacantes se muevan lateralmente dentro de la red. Cada segmento de la red está aislado, y el acceso a cada segmento se controla de manera independiente.

Autenticación y autorización continuas: En lugar de autenticar a los usuarios solo en el punto de entrada, ZTN requiere autenticación continua en cada acceso a recursos críticos. Esto asegura que solo los usuarios y dispositivos autorizados puedan acceder a la información sensible.

Protección contra amenazas internas: Las amenazas internas, ya sean maliciosas o accidentales, son una preocupación significativa para las empresas. ZTN mitiga este riesgo al no confiar implícitamente en ninguna entidad dentro de la red y al monitorear continuamente las actividades sospechosas.

Mejora de la visibilidad y el control: Al implementar políticas de Zero Trust, las empresas obtienen una mayor visibilidad sobre quién accede a qué recursos y cuándo. Esto permite una detección más rápida de actividades anómalas y una respuesta más efectiva a incidentes de seguridad.

Adaptabilidad a entornos cambiantes: Con el aumento del trabajo remoto y el uso de dispositivos personales (BYOD), ZTN proporciona un marco flexible que puede adaptarse a estos cambios. La autenticación y la autorización basadas en el contexto permiten a las empresas mantener la seguridad incluso cuando los empleados acceden a la red desde ubicaciones y dispositivos no tradicionales.

ciberseguridad procesos de empresa con zero trust

¿En qué partes del mundo ya se utiliza el Zero Trust Network como enfoque de seguridad?

El Zero Trust Network ha ganado popularidad a nivel mundial y ha sido adoptado en diversas regiones, incluyendo América del Norte, Europa y Asia-Pacífico. A continuación, se describen algunas de las áreas donde se ha implementado con éxito:

 

Estados Unidos: Como el lugar de origen del concepto de Zero Trust, Estados Unidos ha visto una amplia adopción en sectores como el gobierno, la tecnología y la salud. En 2021, el gobierno de EE. UU. emitió una orden ejecutiva que exige a las agencias federales adoptar principios de Zero Trust para mejorar la ciberseguridad nacional.

 

Europa: En Europa, el Zero Trust se ha convertido en una estrategia clave para cumplir con regulaciones como el Reglamento General de Protección de Datos (GDPR). Países como el Reino Unido, Alemania y Francia han adoptado políticas de Zero Trust en sectores críticos para proteger los datos sensibles y cumplir con las normativas de privacidad.

 

Latinoamérica: Aunque la adopción del Zero Trust en Latinoamérica ha sido más lenta en comparación con otras regiones, países como Brasil, México y Argentina están comenzando a implementar estos principios en sectores clave como la banca y las telecomunicaciones.

Mark Ryland, director de la Oficina del CISO de AWS, y Abby Daniels, gerente de Sector Público de AWS para América Latina. Foto EE: Rodrigo Riquelme

¿Qué empresas u organizaciones han adoptado estrategias de seguridad basadas en Zero Trust Network?

Tech support in data center uses laptop to prevent system overload during peak traffic periods. Hardworking expert in server farm ensuring enough network bandwidth for smooth operations, close up

Muchas empresas y organizaciones líderes en sus respectivas industrias han adoptado estrategias de Zero Trust Network para proteger sus redes y datos. Algunos ejemplos notables incluyen:

Google: Google fue uno de los pioneros en adoptar el enfoque de Zero Trust con su proyecto «BeyondCorp». Esta iniciativa permitió a los empleados acceder a recursos corporativos desde cualquier lugar sin necesidad de una VPN tradicional, basándose en la autenticación y autorización continuas.

Microsoft: Microsoft ha integrado principios de Zero Trust en sus productos y servicios, promoviendo su adopción entre sus clientes. La compañía lo ha implementado en su propia infraestructura para mejorar la seguridad y proteger los datos de los clientes.

CISCO usa el enfoque de seguridad zero trust

Cisco: Cisco ofrece soluciones de Zero Trust a través de su plataforma Cisco Secure, que incluye herramientas para la autenticación multifactor, la segmentación de red y la visibilidad de las amenazas. La empresa ha adoptado estos principios internamente para asegurar su propia red.

IBM empresa que utiliza el enfoque de seguridad zero trust

IBM: IBM ha desarrollado una serie de soluciones de seguridad basadas en Zero Trust, incluyendo la plataforma IBM Security Verify, que ofrece autenticación multifactor y gestión de identidades. IBM también ha implementado Zero Trust en sus operaciones internas para proteger los datos y la infraestructura.

Netflix usa el enfoque de seguridad zero trust

Netflix: Netflix ha adoptado un enfoque de Zero Trust para proteger su infraestructura en la nube y asegurar los datos de los usuarios. La empresa utiliza autenticación continua y segmentación de red para minimizar el riesgo de ataques cibernéticos.

¿Cuál es el posicionamiento del Zero Trust Network en México?

ciberataques a empresas mexicanas

En México, el concepto de Zero Trust Network está ganando tracción a medida que las empresas y organizaciones buscan mejorar sus posturas de ciberseguridad. La adopción de Zero Trust en México se ve impulsada por varios factores:

Incremento de ciberataques: México ha experimentado un aumento en los ciberataques, lo que ha llevado a las empresas a buscar enfoques de seguridad más robustos. Zero Trust ofrece una solución eficaz para proteger contra amenazas internas y externas.

Regulaciones de protección de datos: Las regulaciones de protección de datos, como la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP), requieren que las empresas implementen medidas de seguridad adecuadas para proteger la información personal. Zero Trust ayuda a cumplir con estas regulaciones al asegurar que solo los usuarios autorizados puedan acceder a los datos sensibles.

Adopción de tecnología en el sector financiero: El sector financiero en México ha sido un líder en la adopción de tecnologías de seguridad avanzadas. Los bancos y otras instituciones financieras están implementando Zero Trust para proteger los datos de los clientes y cumplir con las normativas de seguridad.

Iniciativas gubernamentales: El gobierno mexicano está promoviendo la adopción de tecnologías de ciberseguridad para proteger la infraestructura crítica y los datos del gobierno. Esto incluye la promoción de principios de Zero Trust en las agencias gubernamentales.

¿Cómo adoptar el Zero Trust Network permite proteger APIs y crear arquitecturas seguras?

API Security with Zero trust

Las APIs (interfaces de programación de aplicaciones) son componentes esenciales en las arquitecturas modernas, permitiendo la integración y comunicación entre diferentes sistemas y servicios. Sin embargo, las APIs también representan un vector de ataque significativo si no se protegen adecuadamente. La adopción de Zero Trust Network proporciona una capa adicional de seguridad para las APIs y ayuda a crear arquitecturas más seguras mediante:

Autenticación y autorización estrictas: Implementar controles de acceso granulares para cada API, asegurando que solo los usuarios y aplicaciones autorizados puedan interactuar con ellas. Esto incluye el uso de tokens de acceso y la autenticación multifactor para validar cada solicitud.

Segmentación de red y microsegmentación: Dividir la red en segmentos más pequeños y aplicar políticas de seguridad específicas a cada segmento. Esto limita el acceso a las APIs y reduce la superficie de ataque en caso de una brecha de seguridad.

Monitoreo y análisis continuo: Utilizar herramientas de monitoreo para detectar y responder a actividades sospechosas en tiempo real. Esto incluye el análisis de tráfico de API para identificar patrones anómalos y potenciales intentos de ataque.

Cifrado de datos en tránsito y en reposo: Asegurar que todos los datos transmitidos a través de las APIs estén cifrados para protegerlos contra interceptaciones y manipulaciones. Además, cifrar los datos en reposo para garantizar que la información sensible permanezca protegida incluso si se accede a ella sin autorización.

Políticas de acceso basadas en el contexto: Implementar políticas de acceso que consideren el contexto de la solicitud, como la ubicación del usuario, el dispositivo utilizado y el comportamiento habitual. Esto permite una autenticación y autorización más precisa y reduce el riesgo de acceso no autorizado.

Desarrollo seguro y pruebas rigurosas: Adoptar prácticas de desarrollo seguro y realizar pruebas de seguridad exhaustivas en las APIs para identificar y mitigar vulnerabilidades antes de que se desplieguen en producción.

En resumen, el Zero Trust Network es un enfoque de seguridad esencial en el panorama actual de amenazas.

20

En SPS, implementamos un sistema de seguridad en las APIs, lo que permite protegerlas de ser vulneradas, volviéndolas prácticamente invisibles.

Si te interesa conocer más detalles sobre este tipo de implementaciones en tu organización, te invitamos a escribirnos directamente al correo: contactoSPS@spsolutions.com.mx

Con gusto podemos explorar sus alcances dentro de un caso de uso en tu compañía.

 

Autor

Seleni Vargas

Marketing & Content Manager at SPS
LinkedIn
Categorías
Dark Services MuleSoft OCI Zero Trust

A Ray of Light…How to consume a MuleSoft Dark Service API with the Netfoundry.io NodeJS SDK?

A Ray of Light…How to consume a MuleSoft Dark Service API with the Netfoundry.io NodeJS SDK?

A ray of light in the middle of darkness can save your life.

In 1998 Madonna released one of her finest albums whose name was Ray of Light. That song marked the lives of many people during that year. The song was played all over the world.

In this article, we will see how the NodeJS Netfoundry.io SDK can spark the light to consume a Dark Service API. A ray of light within your code is the spark to consume your Dark Services in a highly secured manner.

In our previous article, we’ve learned how to expose a Dark Service API using Netfoundry.io, MuleSoft Anypoint Platform, and Oracle Cloud Infrastructure. In that article, we’ve explained the procedure to deploy APIs as Dark Services and access them from a terminal (laptop) that is sitting on a completely different network. That is already very valuable and powerful at the same time, but we can go even further. And if you are wondering what do we mean by going even further? Just keep reading the article.

 

(Property of Netfoundry.io)

What do we mean by the app is the new edge?

The API consumer (the app) is going to contain the necessary elements to connect with the Dark Service API. The invisibility of the dark service will be lighted (if you will) through the application. The application, through the strong identity, will be entitled to consume the API, not the server, nor any other application running in the same environment, just the entitled application. In fact, for the rest, the Dark Service will remain…pretty much invisible.

This goes beyond just protecting the API with any type of authentication mechanism. When we have a Dark Service API, not only that consumers need to be authenticated to use it, but the strong identity is going to allow us to make it visible, to the rest of the world the Dark Service will remain invisible…

When we incorporate classic mechanisms to authenticate/authorize consumers for our public APIs, for example, OAuth 2.0, even though we add controls to avoid non-authorized consumers to use our APIs, the truth is that our API remains visible to pretty much everyone. A non-authorized consumer may be able to try to get access, to fuzz the requests, to guess the credentials, and in the worst case scenario: to consume it.

With Netfoundry.io we can make our APIs visible just for valid consumers, and invisible to the rest of the world. The consumer application is the edge and is what will contain the right elements to reach the APIs. And that is exactly what we are going to share in this article.

Netfoundry.io offers different SDKs for both enabling Dark Services and consuming them. There are different programming languages you can use for those SDKs, for example, Java, NodeJS, Python, C, Go, etc.

In my case, I will use the NodeJS SDK to consume the Dark API that I published in this article. We have the API already deployed (following the mentioned article) in the MuleSoft Anypoint Platform:

My Dark Service API

This consumer endpoint: http://darskide.api.com is reachable through the internet, but invisible at the same time. Try to access it and you will not reach it. The question is: how can an application get access to it? The response is: through Netroundry.io as we explained in the previous article. But now we will share how the identity can be incorporated into your code that consumes the API, in this case, a very simple NodeJS application.

Our scenario is the following:

a) We need to consume the API from the NodeJS application running in a Digital Ocean droplet

b) As we explained in our previous article, our API is deployed in MuleSoft inside a private Oracle Cloud subnet

c) The API is not reachable from the internet. But we have turned it Dark (invisible) using Netfoundry

d) The NodeJS application running in Digital Ocean will be able to consume the API, and it will be the only piece of software within that droplet that can reach the API (darkside.api.com).

The previous diagram depicts the idea of what we want to achieve. And as you can see the only piece of light that can reach our dark service is that small NodeJS consumer application.

The steps you need to take are:

• Follow this article.

• Create a new endpoint at the Netfoundry.io console

• Download the identity of the endpoint

• Download the NodeJS dependency to incorporate the Netfoundry SDK
• Create a very simple NodeJS application

• Use the identity generated in step #3

• Test your application

 

Let’s create the new endpoint. Go to your Netfoundry.io console and head to the endpoint section:

Click on the blue plus button, and then give it a name and download the key (jwt file):

Then, add this endpoint to the AppWAN:

 

Now, using the ziti-edge-tunnel command line utility:

 

# enroll from a token file
./ziti-edge-tunnel enroll –jwt ./myDarkConsumer.jwt –identity ./myDarkConsumer.json

 

That will produce a json file by the name myDarkConsumer.json that will represent our identity.

Now is the time to create our consumer API code. But first, we need to download the NodeJS dependency. The complete documentation can be found here: https://github.com/openziti/ziti-sdk-nodejs

npm i @openziti/ziti-sdk-nodejs

Once you install the ziti SDK, create a file with the following code and name it callMyDarkService.js:

import ziti from ‘@openziti/ziti-sdk-nodejs’;

const zitiIdentityFile = process.env.ZITI_IDENTITY_FILE;
// Authenticate ourselves onto the Ziti network
await ziti.init( zitiIdentityFile ).catch(( err ) => { /* probably exit */ });

const on_resp_data = ( obj ) => {
console.log(`response is: ${obj.body.toString(‘utf8’)}`);
};

// Perform an HTTP GET request to a dark OpenZiti web service
ziti.httpRequest(
undefined,
‘http://darkside.api.com/’, // Dark Service HTTP URL
‘GET’,
‘/api/people/1’, // path part of the URL including query params
[‘Accept: application/json’ ], // headers
undefined, // optional on_req cb
undefined, // optional on_req_data cb
on_resp_data // optional on_resp_data cb
);

Set the environment variable to point to the identity file:

export ZITI_IDENTITY_FILE=/path_to_your_identity/myDarkConsumer.json

And execute your code:

node callMyDarkService.js

The result:

root@rcarrascogb2:~/nf/samples/node# node callMyDarkService.js
on_req entered: { req: 94757361460352 }
on_resp entered: {
req: 94757361548992,
code: 200,
status: ‘OK’,
headers: {
‘Transfer-Encoding’: ‘chunked’,
‘strict-transport-security’: ‘max-age=15768000’,
allow: ‘GET, HEAD, OPTIONS’,
etag: ‘»ee398610435c328f4d0a4e1b0d2f7bbc»‘,
‘x-frame-options’: ‘SAMEORIGIN’,
vary: ‘Accept, Cookie’,
‘Content-Type’: ‘application/json’,
date: ‘Wed, 21 Dec 2022 22:59:08 GMT’
}
}
response is: {«name»:»Luke Skywalker»,»height»:»172″,»mass»:»77″,»hair_color»:»blond»,»skin_color»:»fair»,»eye_color»:»blue»,»birth_year»:»19BBY»,»gender»:»male»,»homeworld»:»https://swapi.dev/api/planets/1/»,»films»:[«https://swapi.dev/api/films/1/»,»https://swapi.dev/api/films/2/»,»https://swapi.dev/api/films/3/»,»https://swapi.dev/api/films/6/»],»species»:[],»vehicles»:[«https://swapi.dev/api/vehicles/14/»,»https://swapi.dev/api/vehicles/30/»],»starships»:[«https://swapi.dev/api/starships/12/»,»https://swapi.dev/api/starships/22/»],»created»:»2014-12-09T13:50:51.644000Z»,»edited»:»2014-12-20T21:17:56.891000Z»,»url»:»https://swapi.dev/api/people/1/»}

We can call our API which is sitting privately within a private Oracle Cloud Infrastructure subnet, from a Digital Ocean server, and through the internet.

But if we do a ping to the darkside.api.com hostname from the Digital Ocean server, see what happens:

root@rcarrascogb2:~/nf/samples/node# ping darkside.api.com
ping: darkside.api.com: Temporary failure in name resolution

If we try telnet:

root@rcarrascogb2:~# telnet darkside.api.com 80
telnet: could not resolve darkside.api.com/80: Temporary failure in name resolution

From my Digital Ocean server, we can call the Dark API through the NodeJS application, but outside the application, we cannot reach the API. We cannot resolve the hostname, and most importantly we cannot even reach it. Isn’t that interesting?

 

The ray of light that we can use to light the darkness is Netfoundry’s SDK. And as you could see is very simple to incorporate into your code. With that, your consumers’ effort to consume your Dark APIs is very low.

 

In the next article, we’ll elaborate on the idea of how to automate the enrollment of your API consumers.

Autor

Rolando Carrasco

SPS CTO MuleSoft Ambassador. Oracle ACE Director.
LinkedIn
Categorías
Dark Services Zero Trust

The Dark Side of The Cloud: How to create APIs as Dark Services using MuleSoft with Netfoundry.io on top of Oracle Cloud Infrastructure

How to create APIs as Dark Services using MuleSoft with Netfoundry.io on top of Oracle Cloud Infrastructure. The Dark Side of The Cloud

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:

https://www.forbes.com/sites/forbestechcouncil/2022/07/25/how-to-address-growing-api-security-vulnerabilities-in-2022/?sh=2b39f8d15a9e

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:

  1. We have Oracle Cloud (OCI), in my case using the us-ashburn-1 region; within OCI we have a VCN divided into two subnets, but privates.

    2. In one of the subnets, we have a Netfoundry Edge Router

    3. In the second subnet, we have MuleSoft Runtime where our APIs are being developed

    4. We have external developers and organizations who want to consume our APIs through the internet.

    As you can see our MuleSoft Runtimes are not visible from the internet, but at the same time they are reachable to our consumers, using the Netfoundry.io technology.

What do we need to make this possible?

  1. OCI free trial (30 days). We will use two computing instances: one for the Netfoundry Edge Router and one for the MuleSoft Runtime

  2. MuleSoft Anypoint Platform free trial. We will register our Runtime into the Control Plane.

  3. Netfoundry.io teams account. We will provide an overlay network to turn our APIs to the dark side of the cloud.

  4. Your laptop. Where you will be able to consume the APIs

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:

 

  1.  Private Subnet-mydark-vcn. Here we will provide our Netfoundry Edge Router

  2.  Private Subnet-mydark-mule-vcn. Here I will deploy a MuleSoft Runtime

    Before we proceed to provision the rest of the infrastructure, we will create the elements in Netfoundry.

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:

https://swapi.dev/api/people

(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.

Autor

Rolando Carrasco

SPS CTO MuleSoft Ambassador. Oracle ACE Director.
LinkedIn