In the previous module, we talked about networks, but didn't get into a lot of network security concepts. Let's do that now. First, I recommend removing external IPs to prevent access to machines from outside their network whenever possible. Several options are available for securely communicating with VMs that do not have public IP addresses. These services do not have a public IP address because they are deployed to be consumed by other instances in the project, or maybe through dedicated Interconnect options. However, for those instances that do not have an external IP address, it can be a requirement to gain external access, for instance, for updates or patches to be applied. The options for accessing the VMs include a bastion host for external access to private machines, Identity Aware Proxy to enable SSH access or Cloud NAT to provide egress to the Internet for internal machines. The diagram on the right shows an external client accessing Compute Engine resources via a bastion host. The host is behind a firewall where access can be filtered. Whichever method you choose, all internet traffic should terminate at a load balancer, third-party firewall or API Gateway or through Cloud IAP. That way internal services cannot be launched and get public IP addresses. Now, VM instances that only have internal IP addresses can use private Google Access to access Google services that have external IP addresses. The diagram on the right shows a Compute Engine instance accessing a Cloud Storage bucket using its internal IP address. Private Google Access must be enabled when creating the subnet. You can achieve this either with the GCloud command shown here, or through the Cloud Console. Regardless of whether your VM instances have public IP addresses, you should always configure firewall rules to control access. By default, ingress on all port's is denied and all egress is allowed. It's your responsibility to define separate rules to allow or deny access to specific instances for specific IP ranges, protocols, and ports. This graphic shows some scenarios where firewall rules can be configured. Egress from compute Engine to external servers is the first scenario. For ingress, firewall rules should be configured if directs access to an instance is being provided or if via a load balancer. The right-hand graphic shows the scenario of VM instance to instance communication. Firewall rules should be considered here to control access also. Remember, you're still responsible for application level security. If you need to manage APIs, you can use Cloud Endpoints. Endpoints is an API management gateway that helps you develop, deploy, and manage APIs on any Google Cloud Backend. It provides functionality to protect and monitor your public APIs, control who has access using, for example, Auth0 and validate every call with a JSON web token signed with the service account private key. Cloud Endpoints also integrates with identity platform for authentication. All Google Cloud service endpoints use HTTPS. I recommend that you use TLS for your service endpoints. It is your responsibility to configure your service endpoints for TLS. When configuring load balancers only ever create secure front ends. This dialog shows the configuration of a front end and the protocol selected is HTTPS, with the certificate also being selected. Google provides infrastructure DDoS support through global load balancers at level 3 and level 4 traffic. If you have enabled CDN, this will also protect backend resources because a DDoS results in a cache hit instead of hitting your resources as shown on the right. We already mentioned Google Cloud Armor in the networking module. For additional features over the built-in DDoS protection, you can use Google Cloud Armor to create network security policies. For example, you can create allow lists that allow known slash required addresses through and deny lists to block known attackers. This dialog shows a typical security policy configuration where you begin by selecting it as an allow list or a deny list with allow or deny for the rule. If it's a deny, the appropriate action in this example should be a 403 error. In addition to layer 3 and layer 4 security, Google Cloud Armor supports layer 7 application roles. For example, predefined rules are provided for cross-site scripting, XSS, and SQL injection attacks. Google Cloud Armor provides a rules language for filtering request traffic. As an example, consider the first expression on this slide, InIPrange [origin.IP, 9.9.9.0/24]. In this case, the expression returns true if the origin IP in the request is within the 9.9.9.0/24 range. The second line, request.headers [ 'cookie' ].contains[ '80= blah' ] returns true if the cookie AT with Value blah exists in the request header. The third line is true if the origin region code is AU. The expressions can be combined logically with logical AND and OR. The expressions are all assigned to an allow or deny rule that is then applied to incoming traffic.
