Tuesday, March 26, 2024

Read only access to OCI Console.

 If you need read-only access to the Oracle Cloud Infrastructure (OCI) Console, you can achieve this by creating a policy within OCI Identity and Access Management (IAM) that grants only the necessary read permissions to the resources you want to access. The below steps are applicable to identity domains only. To read more about identity domains identity domains in OCI



Here's a general outline of how you might set this up:

1. Create a User

2. Create a group and assign the above created user to group

3. Create a policy in root compartment

Verb:- allow group group_name to read all-resources in tenancy

Note:-Note* Please keep in mind that even though the above users created have only “Read-only” access, they will be able to click certain options such as “create, edit, reboot, terminate, etc”, however, they won’t be able to execute any of these options

Hope this post help someone

Friday, March 22, 2024

Hub and spoke using IP Masquerading in OCI aka Oracle Cloud Infrastructure

 In Oracle Cloud Infrastructure (OCI), the "hub and spoke" architecture is a common networking design used to connect multiple Virtual Cloud Networks (VCNs) in a centralized manner. This architecture is often implemented using Dynamic Routing Gateway (DRG) attachments and Transit Routing. Let me break down how it works:

Hub and Spoke



Hub VCN: In the hub-and-spoke model, one VCN serves as the central hub where shared services or resources are located. This hub VCN typically hosts core services such as DNS, Active Directory, or shared databases.

Spoke VCNs: Spoke VCNs are additional VCNs that are connected to the hub VCN. Each spoke VCN usually contains resources specific to a particular department, application, or environment.

Dynamic Routing Gateway (DRG): The DRG serves as the central routing hub for connecting the hub VCN to other VCNs or on-premises networks. It facilitates the exchange of routing information between the hub VCN and the spoke VCNs.

DRG Attachments: Each spoke VCN is connected to the hub VCN via a DRG attachment. A DRG attachment establishes a logical link between the spoke VCN and the DRG, enabling traffic to flow between them.

Transit Routing: Transit Routing is a feature in OCI that allows you to route traffic between different VCNs using the hub-and-spoke architecture. With Transit Routing, you can configure route tables in the hub VCN to direct traffic between spoke VCNs through the hub VCN.

Route Tables: Each VCN has its own route table that determines how traffic is routed within the VCN. In the hub-and-spoke model, route tables in the hub VCN are configured to route traffic between spoke VCNs.

Security: Security within the hub-and-spoke architecture is typically managed using Security Lists, Network Security Groups (NSGs), and other OCI security features. Access control can be enforced at the subnet level to restrict traffic between different environments.

By implementing a hub-and-spoke architecture using DRG attachments and Transit Routing in OCI, organizations can achieve centralized network management, simplified connectivity between VCNs, and improved security and compliance. This architecture is well-suited for scenarios where multiple VCNs need to communicate with each other while maintaining isolation and security boundaries.

Now, the objective of this post is to explain, how leveraging DRG attachments and VCN Route tables we can make the communication between hub and spoke. And also, using transit route, how we can enable the resources provisioned inside spoke VCN to reach the internet using Hub VCN.

 

Present Architecture:-

Present VCN


Hub:-

Subnet inside HUB


Spoke1 VCN:-

Subnet inside Spoke1 VCN


Spoke2 VCN:-

Subnet inside Spoke2 VCN


The security list at this moment has ingress from spoke1 vcn cidr to spoke2 and vice versa.

I will now try to ping spoke2 instance from spoke1.

As expected, it is not working


Ping result


Create a DRG:-
  


DRG



next, i am going to attach the 2 spokes



Now, under the route table for spokes VCN, we are going to add a new route

Route


Ping is now working on both the side of spokes

ping


The next requirement of this post, is that from spoke VCN, we want to reach to internet via Hub VCN. This will be done via transit route.


In the hub machine compute instance, i'll add a secondary vnic in the same subnet as primary vnic. The subnet is of public type and IGW is attached to it.

Secondary Vnic




Ethernet


Under DRG, create anew distribution list for hub-vcn attachment


DRG Route Distribution List


Create a new DRG route table for hub-vcn


DRG route table

 Attach the hub-vcn to DRG


VCN attachment

Now create a VCN DRG route table and point it to private IP address of secondary vnic


new Route


Add a security list for this public subnet to receive request from spoke VCNs.



Security list for the spoke VCN. Add a ingress rule to receive request from hub vcn




Add the transit route to DRG


transit route

Now, make the nating on the hub-vcn compute instance

sysctl -w net.ipv4.ip_forward=1

firewall-cmd --permanent --direct --add-rule ipv4 nat POSTROUTING 0 \

  -o enp0s6 -j MASQUERADE

 

[root@primary-vnic opc]# firewall-cmd --permanent --zone public --add-interface enp0s6

The interface is under control of NetworkManager, setting zone to 'public'.

success

[root@primary-vnic opc]# firewall-cmd --permanent --zone public --add-masquerade

 

[root@primary-vnic opc]# systemctl restart firewalld

[root@primary-vnic opc]# firewall-cmd --reload

success

[root@primary-vnic opc]#


sysctl -w net.ipv4.conf.all.rp_filter=2


added the route for secondary vnic

[root@primary-vnic opc]# ip route

default via 192.168.0.1 dev enp0s6

default via 192.168.0.1 dev enp0s6 proto dhcp src 192.168.0.49 metric 100

169.254.0.0/16 dev enp0s6 scope link

169.254.0.0/16 dev enp0s6 proto dhcp scope link src 192.168.0.49 metric 100

192.168.0.0/26 dev enp0s6 proto kernel scope link src 192.168.0.49

192.168.0.0/26 dev enp1s0 proto kernel scope link src 192.168.0.57

192.168.0.0/26 dev enp0s6 proto kernel scope link src 192.168.0.49 metric 100

[root@primary-vnic opc]# ip route add 10.10.0.0/26 via 192.168.0.1 dev enp1s0

 

10.10.0.0/26 is the CIDR for spoke1 private subnet

 

Now, if I try to ping google.com from spoke1 vcn




Through this post, i just wanted to show how using IP Masquerading feature we can reach to the internet from the spoke VCN private subnet. Also, how this can be achieved under Hub & Spoke Model. I hope this post will help someone.