Tejas Jain

Container = Namespaces + CGroups + Layered Filesystem Namespaces A namespace wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource. Changes to the global resource are visible to other processes that are members of the namespace but are invisible to other processes. Namespaces limit how much you can see and therefore use: 1. PID 2. Network 3. UTS 4. Mount 5. IPC 6. User CGroups (Control Groups) Control groups are a Linux kernel feature which allows processes to be organized into hierarchical groups whose usage of various types of resources can then be limited and monitored. CGroups limit how much you can use: 1. CPU 2. Memory Layered Filesystem Different files and directory structures are layered in order and on top of each other to be reflected as one directory tree.      Layered Filesystem allows reuse and push/pull deltas. It's an advanced multilayered...

1.  Google Cloud Interconnect Security Cloud Interconnect does not encrypt the connection between your on-premises network and Google's network. Cloud VPN cannot be used with Dedicated Interconnect For additional security, use application-level encryption or your own VPN 2. While using Cloud CDN, the default time-to-live (TTL) for content caching is 3600 seconds = 60 mins 3. Cloud NAT sends only the translation logs and error logs to Cloud Logging service. 4. GCP Dedicated Interconnect - On Premises network device requirements:     10-Gbps circuits, single mode fiber or 100-Gbps circuits, single mode fiber     IPv4 link local addressing     LACP, even if you are using single circuit     EBGP-4 with multi-hop     802.1Q VLANs 5. While using Cloud VPN, the recommended MTU to be configured on the peer VPN  gateway = 1460 bytes 6. Each instance must have at least one network interface. The maximum number of network instances per ...

Virtual Private Cloud (VPC) VPC Networks Global resources (not associated with any zone) and include subnets, routes and firewall rules VPC Networks do not have any IP addresses associated with them (unlike AWS) Resources within a VPC can communicate with one another using the internal IP addresses By default, resources in two different VPCs cannot communicate with each other. The communication can be facilitated by VPC Network Peering VPC networks support IPv4 unicast traffic only. They do not support broadcast, multicast or IPv6 traffic within the network   VPC Subnets Subnets represent VPC Network partitions using one or more useful IP address ranges Subnets are regional resources. Each subnet comprises of a range of IP addresses. These can be primary IP ranges or secondary IP ranges (alias) A network must have at least one subnet before it can be used More than one subnet per region can be created VPC Network supports following modes of subnet creation:     Auto Mode...

Google Cloud Network Constructs VPC VPC Routes Firewall Rules VPC Peering Shared VPC Internal and External IPs Static and Ephemeral IPs VPC Subnets Private Access  VPC Flow Logs Hybrid Connectivity Cloud VPN Cloud Interconnect Cloud Router Cloud NAT Cloud Peering Cloud Load Balancing Cloud CDN Cloud DNS

AWS Organizational Hierarchy AWS Organizations "must" be the starting point of your AWS deployment. (unless you are absolutely sure that it won't scale.. highly unlikely!!) An AWS Organization comprises of multiple "Organizational Units (OUs)". OUs comprise of other OUs or member "AWS Accounts".  Image credits : Here Tip : Design the OUs such that they complement with your organizational hierarchy and businesses and sub-divisions. For eg.  Company XYZ maps to an AWS Organization,     --  Finance maps an OU,         --   Investment Banking within Finance maps to a sub-OU               -- Investment Banking Prod environment maps to an AWS Account               -- Investment Banking Non-Prod environment gets another AWS Account               -- Investment Banking Dev environment gets another AWS Account ...

Google Cloud Armor is Google's Network Security service that provides protection against DDoS and web application based attacks. If you have been thinking about enabling Google Cloud Armor for leveraging its DDoS protection and WAF capabilities, you must know the following restrictions: 1. Cloud Armor cannot be enabled on non-HTTP Load balancers. 2. If your HTTP load balancers have Cloud CDN enabled on them, then you cannot enable Cloud Armor on them.       3. If your HTTP Load Balancer has backend buckets instead of backend services, you cannot enable Cloud Armor. This is evident in the below snapshot, where the only option you get is to enable Armor for "Load Balancer backend service". The above restriction is also mentioned in the official GCP document. Click here :  Cloud Armor Limitations . Summary: You can enable Cloud Armor only on HTTP load balancers which have backend services (not buckets) as the backend resources. 

Centralized collection and storage of traffic logs is one of the most important pieces of any enterprise security environment and it is crucial to have the information about the source (resource requester). In most cases this is as simple as installing an agent on the server and / or forwarding the log files to the log collector / SIEM etc. However, in some cases, it is not so straight forward. Azure Application Gateway Consider an Internet facing application that you have hosted in you Azure infrastructure. Just a quick refresher, an Azure Application Gateway: is an OSI Layer-7 load-balancer is capable of performing an SSL termination is a reverse proxy (like any standard load balancer) is capable of performing health checks of the backend servers (which host the actual application content) and thereby ensure that if one of the backend servers goes down, it automatically stops sending the traffic to this bad server and thereby save you from an outage The following setup shows users en...