Google Cloud Networking overview

How is the Google Cloud physical network organized? Google Cloud is divided into regions, which are further subdivided into zones. A region is a geographic area where the round trip time (RTT) from one VM to another is typically under 1 ms. A zone is a deployment area within a region that has its own fully isolated and independent failure domain. This means that no two machines in different zones or in different regions share the same fate in the event of a single failure. At the time of this writing, Google has more than 27 regions and more than 82 zones across 200+ countries. This includes 146 network edge locations and CDN to deliver the content. This is the same network that also powers Google Search, Maps, Gmail, and YouTube. Click to enlargeGoogle network infrastructureGoogle network infrastructure consists of three main types of networks: Data center network, which connects all the machines in the network together. This includes 100s of 1000s of miles of fiber optic cables including  more than a dozen subsea cables. Software-based private network WAN connects all data centers together Software defined public WAN for user-facing traffic entering the Google network A machine gets connected from the internet via the public WAN and gets connected to other machines on the network via the private WAN. For example, when you send a packet from your virtual machine running in the cloud in one region to a GCS bucket in another, the packet does not leave the Google network backbone. In addition, network load balancers and layer 7 reverse proxies are deployed at the network edge, which terminates the TCP/SSL connection at a location closest to the user — eliminating the two network round trips needed to establish an HTTPS connection.Cloud networking servicesGoogle’s physical network infrastructure powers the global virtual network that you need to run your applications in the cloud. It offers virtual networking and tools needed to lift-and-shift, expand, and/or modernize your applications:Click to enlargeConnectThe first thing you need is to provision the virtual network, connect to it from other clouds or on-premises, and isolate your resources so other projects and resources cannot inadvertently access the network.Hybrid Connectivity: Consider company X, which has an on-premises environment with a prod and dev network. They would like to connect their on-premises environment with Google Cloud so the resources and services can easily connect between the two environments. They can either use Cloud Interconnect for dedicated connection or Cloud VPN for connection via an IPSec secure tunnel. Both work, but the choice would depend on how much bandwidth they need; for higher bandwidth and more data dedicated interconnect is recommended. Cloud Router would help enable the dynamic routes between the on-premises environment and Google Cloud VPC. If they have multiple networks/locations, they could also use Network Connectivity Center to connect their different enterprise sites outside of Google Cloud by using the Google network as a wide area network (WAN). Virtual Private Cloud (VPC): They deploy all their resources in VPC but one of the requirements is to keep the Prod and Dev environments separate. For this the team needs to use Shared VPC, which allows them to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network, so that they can communicate with each other securely and efficiently using internal IPs from that network. Cloud DNS: They use Cloud DNS to manage:Public and private DNS zonesPublic/private IPs within the VPC and over the internetDNS peering ForwardingSplit horizonsDNSSEC for DNS security ScaleScaling includes not only quickly scaling applications, but also enabling real-time distribution of load across resources in single or multiple regions, and accelerating content delivery to optimize last-mile performance.Cloud Load Balancing: Quickly scale applications on Compute Engine—no pre-warming needed. Distribute load-balanced compute resources in single or multiple regions (and near users) while meeting high-availability requirements. Cloud Load Balancing can put resources behind a single anycast IP, scale up or down with intelligent autoscaling, and integrate with Cloud CDN.Cloud CDN: Accelerate content delivery for websites and applications served out of Compute Engine with Google’s globally distributed edge caches. Cloud CDN lowers network latency, offloads origin traffic, and reduces serving costs. Once you’ve set up HTTP(S) load balancing, you can enable Cloud CDN with a single checkbox.SecureNetworking security tools for defense against infrastructure DDoS attacks, mitigating data exfiltration risks when connecting with services within Google Cloud, and network address translation to enable controlled internet access for resources without public IP addresses.Firewall Rules: Lets you allow or deny connections to or from your virtual machine (VM) instances based on a configuration that you specify. Every VPC network functions as a distributed firewall. While firewall rules are defined at the network level, connections are allowed or denied on a per-instance basis. You can think of the VPC firewall rules as existing not only between your instances and other networks, but also between individual instances within the same network.Cloud Armor: It works alongside an HTTP(S) load balancer to provide built-in defenses against infrastructure DDoS attacks. IP-based and geo-based access control, support for hybrid and multi-cloud deployments, preconfigured WAF rules, and Named IP ListsPacket Mirroring: Packet Mirroring is useful when you need to monitor and analyze your security status. VPC Packet Mirroring clones the traffic of specific instances in your Virtual Private Cloud (VPC) network and forwards it for examination. It captures all traffic (ingress and egress) and packet data, including payloads and headers.The mirroring happens on the virtual machine (VM) instances, not on the network, which means it consumes additional bandwidth only on the VMs.Cloud NAT:  Lets certain resources without external IP addresses create outbound connections to the internet.Cloud IAP: Helps work from untrusted networks without the use of a VPN. Verifies user identity and uses context to determine if a user should be granted access. Uses identity and context to guard access to your on-premises and cloud-based applications. Optimize It’s important to keep a watchful eye on network performance to make sure the infrastructure is meeting your performance needs.This includes visualizing and monitoring network topology, performing diagnostic tests, and assessing real-time performance metrics.  Network Service Tiers – Premium Tier delivers traffic from external systems to Google Cloud resources by using Google’s low-latency, highly reliable global network while Standard Tier is for routing traffic over the internet. Choose Premium Tier for performance and Standard Tier as a low-cost alternative.Network Intelligence Center – provides a single console for Google Cloud network observability, monitoring, and troubleshootingModernize As you modernize your infrastructure, adopt microservices-based architectures, and expand your use of containerization you will need access to tools that can help manage the inventory of your heterogeneous services and route traffic amongst them. GKE Networking (+ on-prem in Anthos) – When you use GKE, Kubernetes and Google Cloud dynamically configure IP filtering rules, routing tables, and firewall rules on each node, depending on the declarative model of your Kubernetes deployments and your cluster configuration on Google Cloud.Traffic Director – Helps you run microservices in a global service mesh (outside of your cluster). This separation of application logic from networking logic helps you improve your development velocity, increase service availability, and introduce modern DevOps practices in your organization. Service Directory – Platform for discovering, publishing, and connecting services, regardless of the environment. It provides real-time information about all your services in a single place, enabling you to perform service inventory management at scale, whether you have a few service endpoints or thousands. For a more in-depth look into Google Cloud Networking products check out this.  For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.dev Related ArticleTraffic Director explained!If your application is deployed in a microservices architecture then you are likely familiar with the networking challenges that come wit…Read Article
Quelle: Google Cloud Platform

Beta IPv6 Support on Docker Hub Registry

At Docker we’re all about our community, so we listened to your excitement about Docker Hub support for IPv6 on the public roadmap, and now we are pleased to be introducing beta IPv6 support for the Docker Hub Registry! This means if you’re on an IPv6 only network, you can now opt in to use the registry directly with no NAT64 gateway.

Internet Protocol version 4 (IPv4), in use since the 1980s, can no longer meet the world’s growing demands for globally unique address spaces and this pool will eventually be depleted. IPv6 was created as a replacement for IPv4 and it is anticipated that it will become the new internet protocol standard. This move not only increases access to Docker Hub, but positions Hub to continue being easily accessible as the world transitions to IPv6.

IPv6 adoption of Google users

Docker will now be one of the few container registries that supports IPv6. This update enables more of our community to use the world’s most popular container registry, while making sure Docker Hub is positioned to support our users in the next stage of the internet.

What does this mean for you?

IPv4 Users: Your access to Hub does not change

Dualstack Users: Can choose between IPv4 or IPv6 endpoints

Dualstack users will now be able to use the new IPv6-only endpoints while in beta. At a future point in time, the primary endpoints will also support IPv6.

IPv6 Only Users: able to access new IPv6 only domain

IPv6 only users will now be able to use the beta IPv6 endpoint without the need of a NAT64 gateway!

How to use the beta IPv6-only endpoint

If you are on a network with IPv6 support, you can begin using the IPv6-only endpoint registry.ipv6.docker.com! To login to this new endpoint simply run the following command (using your regular Docker hub credentials):

docker login registry.ipv6.docker.com

Once logged in, add the IPv6-only endpoint to the image you wish to push/pull. For example, if you wish to pull the official ubuntu image instead of running the following:

docker pull ubuntu:latest

you will run:

docker pull registry.ipv6.docker.com/library/ubuntu:latest

Note: library will only be used for official images, replace this with a namespace when applicable. For example pulling docker/dockerfile will be:

docker pull registry.ipv6.docker.com/docker/dockerfile:latest

This endpoint is only supported for push/pulls for Docker Hub Registry with the Docker CLI, Docker Desktop is not supported. The Docker Hub website and other systems will see updates for IPv6 in the future based on what we learn here.

Please note this new endpoint is only a beta – there is no guarantee of functionality or uptime and it will be removed in the future. Do not use this endpoint for anything other than testing.

Implementation

Updating networking infrastructure correctly and in an automated fashion on a high traffic network such as Docker Hub requires precision, delicacy and rigorous testing. A significant number of changes were made across our Amazon Web Services (AWS) network resources and routing stack in order to support IPv6. To give an idea of the process involved, here are some notable highlights:

Rate Limiting

In order to prevent abuse and to enforce our Docker Hub rate limiting, we limit requests based on a user’s IP address. Previously, we were limiting addresses based on the full 32-bit IPv4 addresses. To keep this consistent, we are now limiting based on full IPv4 addresses and the first 64 bits of IPv6 addresses.

We also updated our allowlist systems, which provide our large organization customers and cloud partners with unlimited access to Hub downloads. Similarly, our regulatory blocklist system was updated to include IPv6 addresses.

Load Balancing

For IPv6 connections, we’ve provisioned brand new Network Load Balancers (NLBs) which will be handling all AAAA (IPv6) traffic. These give us more performance and better scalability.

Likewise, our application load balancer configurations were updated to understand IPv6 addresses, pass those along properly to the backend applications, and correctly create logs and metrics based on those.

Software Compatibility

Docker Hub receives billions of requests per day and all of these are logged in order for us to ensure access compliance, security, and also gives us a tool to have more debugging capabilities. Due to this, our tooling and configuration required an update to ensure our logs were consistent with both IPv4 and IPv6.

Alongside logging, some applications needed an update to support Dualstack endpoints – in particular our distribution service which is now providing IPv6 access to our blob storage! Code changes were made to the registry middleware and authentication services to make sure we could serve IPv6 requests across the whole registry push/pull flow.

The Future

We’re thrilled that more users (specifically on IPv6 only networks) will now have better accessibility to Docker Hub! We’re also happy to be supporting the internet and our industry as we make the step into new this IP space.

If you have feedback on this beta release, please let us know here: https://github.com/docker/hub-feedback/issues/2165
The post Beta IPv6 Support on Docker Hub Registry appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Die gemeinsame Nutzung des benutzerdefinierten Frameworks von AWS Audit Manager ist jetzt allgemein verfügbar

AWS Audit Manager bietet jetzt die Möglichkeit, benutzerdefinierte Frameworks auf sichere und einfache Weise über AWS-Konten und -Regionen hinweg gemeinsam zu nutzen. Dies ermöglicht den sofortigen Zugriff auf Ihre benutzerdefinierten Frameworks über mehrere AWS-Konten hinweg, ohne dass Sie die zugrunde liegenden benutzerdefinierten Steuerelemente manuell kopieren oder verschieben müssen. Die gemeinsame Nutzung eines benutzerdefinierten Frameworks ermöglicht einen schnellen Zugriff auf das gemeinsame Framework, so dass Ihre Benutzer immer die aktuellsten und konsistentesten Informationen sehen, die von Ihnen bereitgestellt werden. Sie können die Funktion zur gemeinsamen Nutzung benutzerdefinierter Rahmen in Ihrem AWS Audit Manager-Konto ohne zusätzliche Kosten nutzen.
Quelle: aws.amazon.com

Amazon Connect startet AWS CloudFormation-Support für Benutzer, Benutzerhierarchiegruppen und Betriebszeiten

Amazon Connect unterstützt jetzt AWS CloudFormation für drei neue APIs: Benutzer, Benutzerhierarchien und Betriebszeiten. Sie können jetzt AWS CloudFormation-Vorlagen verwenden, um diese Amazon Connect-Ressourcen — zusammen mit dem Rest Ihrer AWS-Infrastruktur — auf sichere, effiziente und wiederholbare Weise bereitzustellen. Außerdem können Sie diese Vorlagen verwenden, um die Konsistenz zwischen verschiedenen Amazon Connect-Instances zu gewährleisten. Weitere Informationen finden Sie unter Amazon Connect Ressourcentyp-Referenz im AWS CloudFormation-Benutzerhandbuch.
Quelle: aws.amazon.com

Amazon Connect führt API ein, um Betriebszeiten programmatisch zu konfigurieren

Amazon Connect bietet jetzt eine API zur programmgesteuerten Erstellung und Verwaltung von Betriebszeiten. Mit dieser API können Sie programmatisch Betriebszeiten konfigurieren, die in Kontaktflüssen verwendet werden können, um zu entscheiden, an welche Warteschlange Kontakte weiter geroutet werden sollen. Außerdem können Sie jetzt nicht mehr benötigte Betriebszeiten über die Lösch-API löschen. Weitere Informationen finden Sie in der API-Dokumentation.
Quelle: aws.amazon.com

AWS Load Balancer Controller Version 2.3 jetzt mit Support für ALB IPv6-Ziele verfügbar

Der AWS Load Balancer Controller stellt eine Kubernetes-native Möglichkeit zur Konfiguration und Verwaltung von Elastic Load Balancers bereit, die den Datenverkehr an in Kubernetes-Clustern ausgeführte Anwendungen weiterleiten. Elastic Load Balancing bietet mehrere Load Balancers, die alle über die hohe Verfügbarkeit, Auto Scaling und robuste Sicherheit verfügen, die notwendig sind, um Ihre Anwendungen fehlertolerant zu machen.
Quelle: aws.amazon.com