All we could think of imagining a routine day of a NOC guy is looking at all the fancy and colorful multiple screens around, but is this all it?
The answer to the above statement is NO! As a NOC, We have access to the information that is critical to analyze and plot company infra strength and on top of that, access to the servers and protected network makes the situation more critical if thing happens to be in wrong hands.
To support the NOC system, team needs to have access on protected networks in a distributed infrastructure. This could lead to a scenario where every member of the NOC team has its own pair of access keys which may further complicate the access management and make the system more vulnerable.
Here, we are with a solution to unify ever discrete pieces of loosely coupled security, audit and access to our clients most critical and vulnerable information through a single window and since the architecture is more like a micro-service shot of concept it could give us an easily plug-able environment. We call it RAKTBEEJ PROXY.
Solution We Designed
Binding and building all the dependencies into a single environment can’t be better explained than the concept of containerization. RAKTBEEJ PROXY inspired by the same philosophy is the coagulation of such pre-configured containers where each one of them represents an identity of our single client, guarded by a single-window entrance like SSO powered by tools like KeyCloak which allow only the very legitimate users in.
Challenges faced
- Multi VPN support
- Nested virtualization of LAN adapters
- Single Sign ON mechanism
- Managed proxy traffic redirection
- Audit and logging user access
- Automated pipeline for creating clients specific containers.
- Orchestrate container deployment and rollbacks
Why can’t I connect two or more vpn at the same time?
Let’s assume if VPN1 and VPN2 connect the same time or broadcast a route for the same subnet, which does not correspond to the same physical hosts? E.g., you have two Client infra with the exact same configuration Client1 Running some service in address 192.168.0.100.
VM as Solution:- So we decided to use the Isolate environment to perform this task so we started using VM to connect two vpn. But in the VM as the main issue. Memory usage and performance is still a big problem in this approach.
Containers as Solution:- So containers that have lightweight and isolated environments will solve our problem. I decided to go with the container.
Architecture
We used Nginx as Front-end for Path base routing. If we have to connect the VPN1 service, then requests are proxied through the docker container for VPN1. Inside each of the docker containers, a VPN client service is running which is creating a private secure tunnel to its respective VPN server.
Sample Front-End Nginx Config:-
location /service1/ {
proxy_pass http://vpn1/;
}
In the above config, we redirect request to VPN1 Docker container.
In every container also has an Nginx running for route internal requested forward page.
Sample Internal Nginx Config:-
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name localhost;
root /usr/share/nginx/html;
# Load configuration files for the default server block.
# include /etc/nginx/default.d/*.conf;
location / {
auth_basic "Restricted Content";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://192.168.1.100/service1/;
}
after a request receives to container internal Nginx forward the request.
For a single SSO solution, I have integrated Gmail OAuth for authorization by an authenticated user.
In a couple of days, we hope to OpenSource this solution!
Happy Blogging!
Opstree is an End to End DevOps solution provider