Zero effort performance insights for popular serverless offerings

Inevitably, in the lifetime of a service or application, developers, DevOps, and SREs will need to investigate the cause of latency. Usually you will start by determining whether it is the application or the underlying infrastructure causing the latency. You have to look for signals that indicate the performance of those resources when the issue occured. Using traces as your latency signalsIn most instances, the signals that provide the richest information for latency are traces. Traces represent the total time it takes for a request to propagate through every layer of a distributed system, including the load balancer, computes, databases and more during execution. The subset of traces used to represent each layer of the execution are referred to as spans.The difficulty of generating traces has prevented many users from accessing this useful troubleshooting resource. To make them more easily available to developers, we’ve started instrumenting our most popular serverless compute options, AppEngine, Cloud Run and Cloud Functions to generate traces by default. While this will not provide the full picture of what is going on in a complex distributed system, it will provide crucial pieces of information needed to decide which area to focus on during troubleshooting. What do I need to do to get this benefit today?The simple answer is, nothing!  Once your code is deployed in any serverless compute like AppEngine, Cloud Run or Cloud Functions, any ingress or egress traffic through the compute automatically generates spans that are captured and stored in Cloud Trace.  These spans are stored for 30 days at no additional cost.  See additional terms here. The resulting traces can be visualized as waterfall graphs with representative values of latency. In addition, we have extended this capability to Google Cloud databases, with Cloud SQL Insights generating traces representative of query plans for PostgreSQL and sending them to Cloud Trace. The screenshot below is a Day 1 trace captured from a simple “Helloworld” application deployed in Cloud Run. The load balancer span (i.e. root span) is indicative of the total time through Google Cloud’s infrastructure and the Cloud Run span is indicative of the time it took for the compute to execute and service the request. As you can see in the graphic below, the loadbalancer span is roughly equal to the Cloud Run span, so we can conclude that any observed latency is not being caused by Google’s infrastructure. At this point you can focus more on your code.This is awesome, how do I extend it?You must still instrument your application if you want it to generate more granular spans representative of the code’s execution. You can start here to pick the library that matches your development language and for instructions on how to instrument your code. Once this is done, your traces will get richer, encompassing more spans with information about both the performance of the infrastructure and application in one single waterfall view.  Cloud Trace – Google Cloud’s hub for Infrastructure tracesWe are excited about the future of telemetry in Google Cloud. Upcoming releases in the next six months will touch on infrastructure instrumentation and areas like trace analysis, metrics, integrations to other Google Cloud products and integrations with third party APM products. Next StepsExplore the traces from your infrastructure in your Cloud Trace console and explore the available libraries and procedures for application instrumentation. If you have questions or feedback about this new feature, head to the Cloud Operations Community page and let us know!
Quelle: Google Cloud Platform

Zero trust is a must: Supporting our customers with new BeyondCorp Enterprise features

Since launching BeyondCorp Enterprise in January, our team has been busy working with customers to understand how they are using the product and what we can do to better support their needs as they continue on their zero trust journey. We believe zero trust is an effective way to enhance overall security and provide a better user experience and BeyondCorp Enterprise can help make this possible. Today, we’re excited to announce three new BeyondCorp Enterprise features designed to help our customers provide their users simple and secure access to key applications.Certificate-based access via VPC-SCFirst, certificate-based access for GCP APIs via VPC Service Controls (VPC-SC) is now generally available. Using bearer credentials to authenticate access to Cloud Console and Google Cloud APIs is nothing new, but if these credentials are accidentally exposed, they will invariably be found and used by attackers for illegitimate access. Using certificate-based access protects against credential theft or accidental exposure by only granting access when credentials plus a verified device certificate are presented. We now offer native support for client certificates for eight types of VPC-SC resources: GCE, GKE, PubSub, Spanner, Cloud KMS, GCS, BigQuery, and Logging, with more to follow. To begin leveraging certificate-based access for these APIs, visit our documentation page and get started.On-prem connectorNext, we are giving customers a choice for how they connect to on-premises resources with our On-prem connector, which is also now generally available.  Customers can secure HTTP or HTTPS based on-premises applications (outside of Google Cloud) with Identity-Aware Proxy (IAP) by deploying a connector. When a request is made for an on-premises app, IAP authenticates and authorizes the user request and then routes the request to the connector. To deploy the connector for your on-premises applications, see our step-by-step guidance on the Identity-Aware Proxy documentation page.Easy to configure custom access policies Finally, we’re excited to announce the availability of even more zero trust access conditions in Access Context Manager, the zero trust policy engine behind BeyondCorp Enterprise. The ability to leverage new attributes gives administrators even more ways to build fine-grained access control policies to safeguard their applications and Google Cloud resources. Three new sets of attributes are now in public preview and customers can begin using these today:Time and dateWhen evaluating zero trust access, it is often necessary to restrict user access to resources to particular days and time (e.g. shift workers or temporary employees). The time and date restriction is a feature for enterprise customers to enable access controls based on specific times, dates, and/or ranges.Credential strengthConfiguring two-step verification is an important action to prevent security breaches. By leveraging credential strength as another condition in access control policies, enterprises can enforce access controls based on the usage of hardware security keys or other forms of multi-factor authentication. BeyondCorp Enterprise now supports push notifications, SMS codes, 2SV software and hardware keys, one-time passwords, or a general use of any form of MFA.Chrome BrowserTo ensure that users are accessing resources from secure environments, administrators can set zero trust policies that ensure the user’s browser environment has these threat and data protection capabilities turned on. The following are new access conditions that can be used in ACM’s custom access levels: management state, minimum version, real-time URL checks enabled, file upload/download analysis enabled, bulk text (paste) analysis enabled, and security event reporting enabled.We’re just getting startedWe’ll continue to make strides to help our customers. If you’d like to take a deeper look at BeyondCorp Enterprise, check out the BeyondCorp Enterprise Technical Validation report, recently released by the Enterprise Strategy Group. This report provides an assessment of the solution, stating: “ESG validated that configuring BeyondCorp Enterprise to provide secure access to on-premises, SaaS, and cloud applications was quick and easy.”To learn more about these new features and the other exciting work we’re doing in the zero trust space, be sure to register for Google Cloud Next ‘21. We have a great lineup of security sessions planned for you!Related ArticleRegistration is open for Google Cloud Next: October 12–14Register now for Google Cloud Next on October 12–14, 2021Read Article
Quelle: Google Cloud Platform

Manage data exfiltration risks in Cloud Run with VPC Service Controls

Enterprises looking to take advantage of the scalability and ease-of-use associated with cloud technology have often turned to serverless computing architectures. In these systems, a cloud provider allocates resources on-demand as required by a particular workload, and abstracts much of the management of an application or system for a customer. But to the most security-minded enterprises, a serverless architecture can sometimes be confusing due to the black box nature of the security of a fully-managed cloud deployment. An understanding of the underlying security systems within a serverless offering can alleviate those concerns. Many cloud services include identity and access management (IAM) to secure data at the application level. Google Cloud strives be the most trusted cloud, which is why continuously updating our protection capabilities. In addition to IAM, we now support VPC Service Controls for Cloud Run, which creates enterprise-grade security guard rails, protecting your data at the network level while delivering the ease of use and speed to market you expect from a fully-managed system, in a product optimized for container workloads. As organizations plan cloud migrations, they often find that familiar security strategies, such as using firewalls to segment applications aren’t applicable when those apps are re-architected to take advantage of managed cloud services like Cloud Run. With VPC Service Controls (VPC-SC), administrators can define a security perimeter around Google-managed services to control communication to and between those services. Using VPC-SC, you can isolate your production GCP resources from unauthorized VPC networks or the internet, and isolate both production GCP resources and production VPC networks from unauthorized GCP resources.VPC Service Controls (VPC SC) give you fine-grained control over how data moves into and out of a VPC SC service perimeter. VPC SC provides an additional layer of security defense for Google Cloud that is independent of Identity and Access Management (IAM). IAM currently enables granular identity based access control; VPC SC enables a security parameter that lets you secure your cloud resources and set up private connectivity to Google Cloud’s APIs and services.This helps protect against risks including:Data exfiltration from malicious insiders or compromised codeAccidental public exposure of private data, caused by misconfigured IAM policiesAccess from unauthorized networks using stolen credentialsUsing VPC Service Controls for Perimeter Security So how does this work? Let’s imagine you are using a Cloud Run service to do some data processing. When a push notification comes in from PubSub, your service reads data from Google Cloud Storage, performs data processing and writes the results back to Cloud Storage. In this example, access to both the dashboard and the data processing endpoint is protected by IAM.Here is what this system looks like:When this system is brought to production, it will be able to access sensitive data. While IAM protection is useful, it doesn’t completely protect against some avenues for data exfiltration. For example, malicious insiders could modify the service to write the output data to an unauthorized location on the internet via an HTTP call. We also don’t want to be in a position where one misconfigured permission can put our data at risk.To introduce a second layer of security, we put our Cloud Run service inside a VPC SC perimeter by following the VPC SC integration guide for Cloud Run. We also enforce VPC SC on all other APIs our developers have access to. Here is the modified system:The Cloud Run service as well as the Cloud Run Admin API (used for deploying and managing the service) are now protected by the VPC SC service perimeter. This means that any requests to the Cloud Run Admin API or the endpoint of the Cloud Run service itself are now checked against the VPC SC policy.This new setup helps prevent against more potential attacks. For example, a malicious insider with permissions on the Cloud Run service can no longer:Redirect output from the service to a Cloud Storage bucket in a project under their control, outside the perimeterChange the service to access or send data to arbitrary internet resources by altering the service’s egress settings to values incompatible with the Organization Policy. To allow services with legitimate requirements to communicate with the outside world, there are ways to give external resources access to resources inside the perimeter through auditable policies. Here are some examples:You can use VPC SC Ingress policies to allow admins access to the Cloud Run Admin API, so they can continue to manage and update the service from outside the perimeter (e.g. from their company-issued laptops). You can set up VPC Firewall rules to allow access from the Cloud Run service to specific resources outside the perimeter. This is useful if, for example, our service needs to access a resource outside GCP as an input for its data processing. If you  need to give someone outside of the parameter access to the service while ensuring protection,  you can set up Cloud Load Balancing for the service and then use Cloud Armor and Cloud IAP to selectively allow access to the service. This is useful, for example, to give developers access to a dashboard exported by your service.Enhanced enterprise securityVPC SC enhances the picture for your enterprise serverless needs. With Cloud Run, Google Cloud manages your server infrastructure for you. This enables you to benefit from Google’s sophisticated approach to multi-project API security perimeters for Google APIs. This extends existing serverless security benefits such as host level patches and network infrastructure security, freeing up your team’s time for strategic work. Earlier this year we announced four new features to secure your Cloud Run services, including Secret Manager integration, Binary Authorization, customer managed encryption keys, and recommendations for permissions based on the principle of least privilege in Recommendation Hub.Cloud Run also has a complete set of network ingress and egress controls.With the addition of VPC SC, Cloud Run now has a fully featured set of security controls, enabling easier network governance and greater peace of mind. Learn how to set up and use VPC SC for Cloud Run today.Related Article4 new features to secure your Cloud Run servicesWe’re improving the security of your Cloud Run environment with things like support for Secret Manager and Binary Authorization.Read Article
Quelle: Google Cloud Platform

Listen up! Google Cloud Reader reaches 50 episodes