Building a resilient architecture with Cloud SQL

Customers build and deploy many applications that have varied requirements from an availability perspective. The databases that store and manage the data created and used by these applications play a key role in determining the overall availability of the applications. Some applications can tolerate a longer recovery time or RTO (Recovery Time Objective) and have ways to deal with some amount of data loss or RPO ( Recovery Point Objective). Other critical applications have a requirement for no data loss i.e. the RPO has to be zero and be able to return to service quickly i.e. a short RTO.. The databases supporting these applications should have capabilities to meet the various RPO and RTO requirements that the applications need. Cloud SQL is Google Cloud’s fully managed relational database service for MySQL, PostgreSQL, and SQL Server. It provides full compatibility with the source database engines while reducing operational costs by automating database provisioning, storage capacity management, and other time-consuming tasks. Cloud SQL has built-in features to ensure business continuity with reliable and secure services, backed by a 24/7 SRE team providing a 99.95% SLA for the service.This guidediscusses the features in Cloud SQL that can be used to build a resilient database architecture. We list the planned and unplanned events that can impact the availability of the Cloud SQL instance. We discuss the unique capabilities of Cloud SQL that can control and limit the impact of planned maintenance events in terms of downtime. Planned events could be configuration updates or patching activities that are needed to keep the database instance in optimal health.We look at the various types of unplanned events that can cause an outage and discuss features that can be used by customers to reduce the RPO and RTO. The features include  database backup and recovery capabilities that form the foundation of an availability strategy and can protect against failures and human errors and reduce the data loss exposure to a minimum.For environments where the RPO needs to be zero, we discuss the Cloud SQL High Availability configuration that provides a RPO of zero. The replication capabilities of Cloud SQL and how replicas can be used in an availability architecture, both in the same region and using cross-region replicas as a building block to address the disaster recovery requirements, are also covered in the guide.Finally, the guide briefly discusses best practices for applications to manage connections to the database, use observability to monitor load on the database and handle failures gracefully.
Quelle: Google Cloud Platform

Google Cloud Certifications adds new sustainable benefits and donation opportunities

We are thrilled to announce some new Google Cloud certification benefits that reinforce our commitment to Google Cloud certified individuals and our global sustainability strategy. Read on for a look at what’s to come for our certified community.New Google Cloud certified digital toolkit for all Google Cloud certified individualsAn official Google Cloud certified digital toolkit will now be awarded to all Google Cloud certified and recertified individuals, including those with the Cloud Digital Leader, Associate Cloud Engineer, and Professional Google Cloud certifications. The assets in this digital toolkit are an exciting new addition to the Google Cloud certification benefits, and were designed to help any Google Cloud certified individual show off their certification accomplishment. And the best part –  they’re instantly available once becoming officially Google Cloud certified. Keep an eye out for new designs that will become available to the Google Cloud certified community on an ongoing basis.The assets include: Google Cloud Certified Google Meet background: Use this digital background to proudly display your certified status during Google Meet meetings Google Cloud Certified official email signature: Use this template to easily add your Google Cloud certification(s) on your email signatureGoogle Cloud Certified social media profile banner: Update your LinkedIn profile with a banner to better stand out across your network#GoogleCloudCertified social media bannerOur Google Cloud certified community can access their digital toolkit in the Google Cloud Certified Group.Sustainable options for Google Cloud certified professional merchandiseIndividuals who become newly Google Cloud certified at the professional level will unlock exclusive Google Cloud certified professional merchandise, which will now be shipped in sustainable, low carbon-footprint shipping boxes – that are reusable and made with 100% recycled materials. We are excited to also launch a new global fulfillment platform that will allow us to fulfill orders locally in Europe and India.  This will not only deliver items faster but will also reduce carbon emissions from transit.  Merchandise will continue to be sourced through sustainable suppliers that align with Google’s sustainability practices.The merchandise unlocked by individuals who achieve a Professional Google Cloud certification features brands that respect our planet, such as Timbuk2, which uses 100% nylon and polyester from  pre- and post- consumer materials to construct their backpacks. Celebrate your Google Cloud certification with a charitable donationIn lieu of selecting merchandise, individuals who certify or renew a professional level certification can celebrate their certification by requesting Google Cloud to donate ($55 USD) to one of two charitable organizations. We’re proud to share that we’re working with Pratham.org, one of the largest NGO organizations in India that focuses on improving the quality of education in India and ALERTWildfire, a network of nearly 1,000 specialized camera installations used by first responders and volunteers to detect, monitor, and fight wildfires before they become too big. The cameras also support critical evacuation efforts by relaying real-time information when it’s needed most.Interested in becoming Google Cloud certified? Check out our Google Cloud certifications and take advantage of the available Google Cloud certified benefits.
Quelle: Google Cloud Platform

Announcing Apache Iceberg support for BigLake

Apache Iceberg is a popular open source table format for customers looking to build data lakes. It provides many features found in enterprise data warehouses, such as transactional DML, time travel, schema evolution, and advanced metadata that unlocks performance optimization. Iceberg’s open specification allows customers to run multiple query engines on a single copy of data stored in an object store. Backed by a growing community of contributors, Apache Iceberg is becoming the de facto open standard for data lakes, bringing interoperability across clouds for hybrid analytical workloads and systems to exchange data. Earlier this year, we announced BigLake, a storage engine that enables customers to store data in open file formats (such as Parquet) on Google Cloud Storage and run GCP and open source query engines on it in a secure, governed, and performant manner.  BigLake unifies data warehouses and lakes by enabling BigQuery and open source frameworks like Spark to access data with fine-grained access control. Today, we are excited to announce that this support now extends to the Apache Iceberg format, enabling customers to take advantage of Iceberg’s capabilities to build an open format data lake while benefiting from native GCP integration using BigLake. “Besides BigQuery, a large segment of our data is stored on GCS. Our Datalake leveraged Iceberg to tap into this data in an efficient and scalable way on top of incredibly large datasets. BigLake integration makes this even easier by making this data available to our large BigQuery user base and leverage its powerful UI. Our users now have the ability to realize most BigQuery benefits on GCS data as if this was stored natively.”  — Bo Chen, Sr. Manager of Data and Insights at Snap Inc.Build a secure and governed Iceberg data lake with BigLake’s fine-grained security modelBigLake enables multi-compute architecture: Iceberg tables created in supported open source analytics engines can be read using BigQuery.code_block[StructValue([(u’code’, u”# Creation of table using Iceberg format with Dataproc Spark rnrnCREATE TABLE catalog.db.table (col1 type1, col2 type2) USING iceberg TBLPROPERTIES(bq_table='{bigquery_table}’, bq_connection='{bigquery_connection}’);”), (u’language’, u”), (u’caption’, <wagtail.wagtailcore.rich_text.RichText object at 0x3edb58d5c110>)])]Once the table has been created in Spark, easily query using BigQuery:code_block[StructValue([(u’code’, u’# Query table using the BigQuery console rnrnSELECT COL1, COL2 FROM bigquery_table LIMIT 10;’), (u’language’, u”), (u’caption’, <wagtail.wagtailcore.rich_text.RichText object at 0x3edb59443e10>)])]Apache Spark already has rich support for Iceberg, allowing customers to use Iceberg’s core capabilities, such as DML, transactions, and schema evolution, to carry out large-scale transformation and data processing. Customers can run Spark using Dataproc (managed clusters or serverless), or use built-in support for Apache Spark in BigQuery (stored procedures) to process Iceberg tables hosted on Google Cloud Storage. Regardless of your choice of Spark, BigLake automatically makes those Iceberg tables available for end users to query.Administrators can now use Iceberg tables, similar to BigLake tables, and don’t need to provide end users access to the underlying GCS bucket. The end user access is delegated through BigLake, simplifying access management and governance.  Administrators can further secure Iceberg tables using fine-grained access policies, such as row, column level access control, or data masking, extending the existing BigLake governance framework to Iceberg tables. BigQuery utilizes Iceberg’s metadata for query execution, providing a performant query experience to end users.This set of capabilities enables customers to store a single copy of data on object stores using Iceberg and run BigQuery as well as Dataproc workloads on it in a secure, governed, and performant manner, eliminating the need to duplicate data or write custom infrastructure. For GCP customers who store their data on BigQuery Storage and Google Cloud Storage, BigLake now further unifies data lake and warehouse workloads.  Customers can directly query, join, secure, and govern data across BigQuery storage and Iceberg tables on Google Cloud Storage. In the coming months, we will extend Apache Iceberg to Amazon S3 and Azure data lake Gen 2, enabling customers to build multi-cloud Iceberg data lakes. Differentiate your Iceberg workloads with native BigQuery and GCP integrationThe benefits of running Iceberg on Google Cloud extend beyond realizing Iceberg’s core capabilities and BigLake’s fine-grained security model. Customers can use native BigQuery and GCP integration to use BigQuery’s differentiated services on Iceberg tables created over Google Cloud Storage data. Some key integrations most relevant in the context of Iceberg are:  Securely exchange Iceberg data using Analytics Hub – Iceberg as an open standard provides interoperability between various storage systems and query engines to exchange data. On Google Cloud, customers use Analytics hub to share BigQuery & BigLake tables with their partners, customers, and suppliers without needing to copy data. Similar to BigQuery tables, data providers can now create shared datasets to share Iceberg tables on Google Cloud storage. Consumers of the shared data can use any Iceberg compatible supported query engine to consume the data, providing an open and governed model of sharing and consuming data.  Run data science workloads on Iceberg using BigQueryML – Customers can now use BigQueryML to extend their machine learning workloads to Iceberg tables stored on Google cloud storage, enabling customers to realize AI value on data stored outside of BigQuery. Discover, detect and protect PII data on Iceberg using Cloud DLP – Customers can now use Cloud DLP to identify, discover and secure PII data elements contained in Iceberg tables, and secure sensitive data using BigLake’s fine-grained security model to meet workload compliance.Get Started Learn more about BigLake support for Apache Iceberg by watching this demo video, and a panel discussion of  customers building using BigLake with Iceberg. Apache Iceberg support for BigLake is currently in preview, sign up to get started. Contact a Google sales representative to learn how Apache Iceberg can help evolve your data architecture.Special mention to the engineering leadership of Micah Kornfield, Anoop Johnson, Garrett Casto, Justin Levandoski and team to make this launch possible.
Quelle: Google Cloud Platform

Introducing Sensitive Actions to help keep accounts secure

At Google Cloud, we operate in a shared fate model, working in concert with our customers to help achieve stronger security outcomes. One of the ways we do this is to identify potentially risky behavior to help customers determine if action is appropriate. To this end, we now provide insights on what we are calling Sensitive Actions. Sensitive Actions, now available in Preview, are focused on understanding IAM account, or user account, behavior. They are changes made in a Google Cloud environment that are security relevant — and therefore important to be aware of and evaluate — because they may be precursors to an attack, an effort to make other attacks possible, or part of an effort to monetize a compromised account. They can quickly highlight potentially malicious activities that are facilitated by authentication cookie theft, and are another defense-in-depth mechanism that Google Cloud offers to help address this attack vector. The Sensitive Actions that are detected today will appear in two places. They are available in Security Command Center Premium, the primary source for security and risk alerts in Google Cloud, as Observations from the Sensitive Actions Service. They are also available in Cloud Logging, where we recommend that customers integrate them into their monitoring workflows. Sensitive Actions include the following list of action names (mapped to the MITRE ATT&CK tactics that these actions may correspond to) and descriptions: To ensure that adversaries do not have mechanisms to disable this protection or hide logs from users, Sensitive Actions is an on-by-default service now enabled for Cloud customers. In cases where customers have certain privacy controls or policy restrictions applied to their logging pipeline, their logs will not be analyzed by this service.You can learn more about Sensitive Actions and our overall recommendations for keeping your account secure by visiting our documentation here.
Quelle: Google Cloud Platform

Developer Engagement in the Remote Work Era with RedMonk and Miva

With the rise of remote-first and hybrid work models in the tech world, promoting developer engagement has become more important than ever. Maintaining a culture of engagement, productivity, and collaboration can be a hurdle for businesses making this new shift to remote work. But it’s far from impossible.

As a fully-remote, developer-focused company, Docker was thrilled to join in a like-minded conversation with RedMonk and Miva. Jake Levirne (Head of Product at Docker) was joined by Jon Burchmore (CTO at Miva) for a talk led by RedMonk’s Sr. Analyst Rachel Stephens. In this webinar on developer engagement in the remote work era, these industry specialists discuss navigating developer engagement with a focus on productivity, collaboration, and much more.

Navigating developer engagement

Companies with newly-distributed work environments often struggle to create an engaging culture for their employees. This remains especially true for the developer workforce. Because of this, developer engagement has become a priority for more organizations than ever, including Miva.

“We actually brought [developer engagement] up as a part of our developer roadmap. As we were talking about ‘this is our product roadmap for 2022 — what’s the biggest challenge?’, my answer was ‘keeping people engaged so that we can keep productivity high.’” Jon Burchmore

Like Miva, other organizations are starting to incorporate developer engagement into their broader business decisions. Teams are intentionally choosing tools and processes that support not only development requirements but also involvement and preference. By taking a look at productivity and collaboration, we can see the impact of these decisions. 

Measuring developer productivity and collaboration

As both an art and a science, measuring developer productivity and collaboration can be difficult. While metrics can be informative, Jon is most interested in seeing the qualitative impact.

“How much is the team engaging with itself […] and is that engagement bottom up […] or from peer-to-peer? And a healthy team to me feels like a team where the peers are engaging as well. It’s not everyone just going upstream to get their problems solved.” Jon Burchmore

As Jake adds, it’s more than just tracking lines of code. It’s about focusing on the outcomes. While developer engagement can be difficult to measure, the message is clear. Engaged developers are non-negotiable for high-performing teams.

Approaching developer collaboration

Developer collaboration is another linchpin for building developer engagement. Teams are now challenging themselves to find more opportunities for pair programming or similar types of coworking. Healthy collaboration should also not be limited to single teams.

“When you unlock collaboration both within teams and across teams, I think that’s what allows you to build what effectively are the increasingly complex real-world applications that are needed to keep creating business value.” Jake Levirne

Organizations are taking a more holistic, inter-team perspective to avoid the dreaded, siloed productivity approach.

Watch the full, on-demand webinar

These points are just a snapshot of our talk with RedMonk and Miva on the challenges of developer engagement in the remote work era. Hear the rest of the discussion and more detail by watching the full conversation on demand.
Quelle: https://blog.docker.com/feed/

Security Advisory: CVE-2022-42889 “Text4Shell”

What is it?

CVE-2022-42889, aka “Text4Shell”, is a vulnerability in the popular Java library “Apache Commons Text” which can result in arbitrary code execution when processing malicious input. More information can be found at GitHub advisory or this Apache thread.

What can an attacker do?

If you’re vulnerable, an attacker can inject malicious input containing keywords which can trigger: 

a DNS requesta call to a remote URLan inline script to execute

These three mechanisms will be executed on the server and can trigger arbitrary code to execute, pulling code from external sources or embedding arbitrary scripts.

This makes this vulnerability highly serious, although, in many cases, consumers of this library won’t be vulnerable due to not using the StringSubstitutor class (as below) and/or not passing in untrusted input into vulnerable functions.

Security researchers are also reporting that increased and significant activity to exploit this vulnerability is being recorded.

Am I vulnerable?

To be vulnerable, you must:

Use Apache Commons Text version 1.5-1.9 inclusiveHave code using the StringSubstitutor class with variable interpolationHave a mechanism of accepting input and passing it into the StringSubstitutor class

Docker vulnerability scanning tools including the docker scan CLI and Docker Hub Vulnerability Scanning, powered by Snyk, will detect the presence of the vulnerable versions of the library and flag your image as vulnerable (see below).

Note that you may not be vulnerable even if you’re using these versions, as your code paths may already mitigate this by either not using the vulnerable methods, or by not passing in user input into them (see the Mitigations section below). This may be difficult to validate, however, without understanding all the code paths in detail and where they may get input from. So the easiest fix is simply to upgrade all applications depending on vulnerable versions.

You can use docker scan to check if the image has the vulnerability. If Text4Shell is present you will see a message in the output log like this:

  Upgrade org.apache.commons:commons-text@1.9 to org.apache.commons:commons-text@1.10.0 to fix
✗ Arbitrary Code Execution (new) [High Severity][https://security.snyk.io/vuln/SNYK-JAVA-ORGAPACHECOMMONS-3043138] in org.apache.commons:commons-text@1.9
introduced by org.apache.commons:commons-text@1.9

To test this, you can check a vulnerable image, for example this neo4j image contains a vulnerable version of commons-text at /var/lib/neo4j/lib/commons-text-1.9.jar:

docker scan neo4j:latest@sha256:17334cbc668d852ca8a3d8590f66c4fda64d9c7de7d93cc62803f534ae7dbce6

Docker Hub scans

As of 12:00 UTC 21 October 2022, Docker Hub now identifies the Text4Shell vulnerability and will badge any image it finds vulnerable. This badge will be publicly visible for Docker Official Images and Docker Verified Publisher images, and privately visible for any other images with vulnerability scanning enabled.

Scans before this date may not reflect this vulnerability, however, we will continue to scan older Docker Official and Docker Verified Publisher images and will update the badges as the results are checked.

If an image has been scanned and is found to be affected by the Text4Shell vulnerability, then you’ll see the below badging and information next to the image:

Mitigations

The safest mitigation to execute is to update to version 1.10 of Apache Commons Text.

If updating to this version isn’t possible, the secondary mitigation is to check usage closely across your codebase and ensure untrusted user input isn’t being passed to the vulnerable functions.

Docker Official Images

A number of the Docker Official images do contain the vulnerable versions of Apache Commons Text. These will be publicly labeled in the Docker Hub user interface. For more detailed information on the current status of Docker Official Images please see https://docs.docker.com/security/.

Other images

We’re working with the Docker Verified Publishers to identify and update their affected images. We’re also looking at ways to highlight images that are affected, and we’ll continue to update this post as we have more information.

Is Docker infrastructure affected?

Docker Desktop and Docker Hub are not affected by the Text4Shell vulnerability. Docker largely uses Go code to build our applications, not Java. Although we do use some Java applications, we have confirmed we aren’t vulnerable to CVE-2022-42889.
Quelle: https://blog.docker.com/feed/

AWS Glue führt Git-Integration ein

AWS Glue bietet jetzt Integration mit Git, dem weit verbreiteten Open-Source-Versionskontrollsystem. AWS Glue ist ein serverloser Datenintegrationsservice, der wiederverwendbare Aufträge verwendet, um an Datensätzen von nahezu jeder Größe ETL (Extract, Transform, Load)-Aufgaben durchzuführen. Mit dieser Funktion können Kunden GitHub und AWS CodeCommit verwenden, um einen Änderungsverlauf ihrer AWS-Glue-Aufträge aufzuzeichnen und ihre bestehenden DevOps-Methoden anzuwenden, um diese Aufträge auszuführen. Zuvor mussten Kunden ihre eigenen Integrationen mit ihren Codeversionsverwaltungssystemen einrichten und Tools entwickeln, um Aufträge aus Entwicklungs- in Produktionsumgebungen zu verschieben.
Quelle: aws.amazon.com

Mit Host Auto-Failover Verfügbarkeit von SAP-HANA-Systemen in AWS verbessern

Sie können jetzt SAP-HANA-Systeme mit Host Auto-Failover in AWS verbessern. Host Auto-Failover ist eine vollständig automatisierte Host-Fehlerwiederherstellungslösung für SAP HANA, mit der Sie einen oder mehr Hosts im Standby-Modus zu einem SAP-HANA-System hinzufügen können. Mit Host Auto-Failover kann SAP HANA automatisch Host-Ausfälle erkennen (EC2-Instance, OS-Ebene oder SAP HANA) und ein automatisiertes Failover zu einem Standby-Host auslösen, damit Sie automatisch innerhalb von Minuten wiederherstellen können.
Quelle: aws.amazon.com

Amazon EC2 Auto Scaling unterstützt jetzt die voraussagende Skalierung in der Region Asien-Pazifik (Jakarta)

Amazon EC2 Auto Scaling unterstützt jetzt die voraussagende Skalierung in der Region Asien-Pazifik (Jakarta). Mit der voraussagenden Skalierung können Sie Ihre Auto-Scaling-Gruppe proaktiv skalieren, um auf die kommende Nachfrage vorbereitet zu sein. Auf diese Weise vermeiden Sie eine übermäßige Bereitstellung von Kapazität, was zu niedrigeren EC2-Kosten führt und gleichzeitig die Reaktionsfähigkeit Ihrer Anwendung gewährleistet. Um eine Liste der unterstützten öffentlichen AWS-Regionen und AWS-GovCloud-Regionen zu sehen, klicken Sie hier.
Quelle: aws.amazon.com