How to configure IP masquerade agent in GKE Standard clusters

Key Takeaways

foreign [Music] to another by modifying either the source or destination address information in the IP header IPS grading is a form of nat that is typically used to perform many to one address translation via multiple Source IP addresses are masked behind a single IP address this helps improve security and decreases the number of IB addresses your organization needs in this video you will learn how ipmashgrading Works in Google kubernetes engine what components are involved in configuring it how to configure it in a gke standard cluster and finally how to troubleshoot and resolve a common issue with ipmask grading let's get started inside a GK cluster pods usually have private IP addresses from RSC 1918 ranges which are not routable on the public internet so when a pod sends Network traffic to a destination on the public internet IPS grading is used to change the source IP address of packets sent from the part to the underlying notes IP address this is also useful when a recipient is configured to receive packets only from the Clusters node IP addresses on Linux nodes GK configures iptable rules to perform IP mask reading GK uses the ipmask agent which runs as a demon set in your cluster to configure the appropriate data plane the ipmask agent configures iptable rules in a node to handle the mask reading of pod IP addresses when sending traffic to other nodes or destinations outside the cluster this essentially hides pod IP addresses behind the cluster node's IP address this will be helpful especially in scenario where it is expected that traffic to external addresses must come from known machine addresses the two main components involved in configuring IP mask reading in gke are the ipmask agent demon set which is responsible for configuring the necessary iptable rules to perform Source address translation in the Linux kernel and uses the ipmask agent config map the ipmask agent config map enables you to specify a range of destination IP addresses for which the Parts Source IP address is preserved when packets are sent out alright let's take a look at the steps involved in configuring ipmask grading NGK Step 1 check if the IP mask agent demands it and config map are present in your cluster if not use the below link to create these resources Step 2 create and update the ipmask agent config map here is a sample ipmask agent config map for reference by default every outbound connection undergoes IP mask reading except the default non-masquerade cidrs for example if you want to preserve a pod's IP address then you must Define a list of destination IB addresses in cidr format under the non-masquerade cidr option when packets are sent to these destinations your cluster does not masquerade The Source IP address and thereby press of pod IP addresses all other destinations that are not part of non-masquerade cidrs list undergo Source address translation let's dive into a demo and learn how to troubleshoot and resolve a common issue that can be seen if IP mask reading is not configured correctly consider the following scenario a client part running inside a GK cluster with connectivity to on-prem using Cloud VPN there is an application running on on-prem with the IP address 10.151.0.2 which needs to be accessed from the client part the on-prem application is configured such that it accepts connections only from the powered IP addresses let's now make an HTTP request from the client to the on-prem application oops it's not working this is because the pods IP address is mass graded behind the node's IP address to fix this issue you must disable ipmask reading of powered IP address when the destination is on-prem application check if the IP mask agent is running inside the cluster by running the following command this indicates the ipmask agent is running inside the cluster as a demon said check the IP mask kitchen config map from the GK console select the option secrets and config map unselect the option is system object false search for IP mask agent resources select it click on the edit button under the non-masquerade cidr block add the Range 10.151.0.2 32 to prevent IP Mass grading for any traffic going to the on-prem application save the changes let's try make the HTTP request from the client to the on-prem success the connectivity between the Pod and the on-prem application is now working successfully for more details about ibmask rating in gke check out the following documents thanks for watching the video [Music]