Interview: Fabrizio Pilotti, CIO, Aston Martin Formula One
Managing IT for a Formula One racing team is almost as much of a high-speed experience as the cars themselves – and tech is becoming more and more embedded into the sport

325 articles
325 ARTICLES
Managing IT for a Formula One racing team is almost as much of a high-speed experience as the cars themselves – and tech is becoming more and more embedded into the sport


One of the myths of post-quantum computing is that IT leaders can make no meaningful progress until they launch a dedicated transformation programme, but there are simple, impactful steps you can take today

New research finds 100,000 of Japan’s AI developers now leverage cloud native technologies Key Highlights: YOKOHAMA – KubeCon + CloudNativeCon Japan —July 29, 2026— The Cloud Native Computing Foundation® (CNCF®), which builds sustainable ecosystems for cloud…

New architecture reduced AI container image pull times by 60x while automating workflows for next-generation driver assistance systems Key Highlights YOKOHAMA – KUBECON + CLOUDNATIVECON JAPAN — July 29, 2026 — The Cloud Native Computing Foundation®…

Following macOS and FreeBSD guests in v2.1, Lima v2.2 takes the next big step: Windows guest support. With this release, a single limactl workflow can now boot Linux, macOS, FreeBSD and Windows virtual machines. Lima v2.2…

We are thrilled to announce that CoHDI has officially been accepted as a Cloud Native Computing Foundation (CNCF) Sandbox project! This acceptance into the CNCF Sandbox marks an important milestone in CoHDI’s journey. We would like…

The first KubeCon + CloudNativeCon Japan took place in Tokyo in June 2025 and kicked off a cloud native skills boom in the region. In the twelve months since the conference, Kubernetes exams taken in Japan…

The Kubeflow news coming out of Kubecon + CloudNativeCon Japan 2026 highlights several significant advancements and community initiatives. The Kubeflow project is rapidly advancing toward CNCF Graduation, emphasizing its evolution into a mature, production-ready ML ecosystem….

Increasing the adoption of generative AI across the enterprise requires you to do more than deploy a generic chatbot with a custom wrapper. Interacting with business-critical databases demands absolute trust, strict governance, and deep grounding in enterprise semantics. Over the last year, Conversational Analytics (CA) in Google Cloud has moved from isolated experiments to scaled, enterprise-wide deployments. BigQuery Conversational Analytics and the Conversational Analytics API are now generally available, adding to the general availability of Conversational Analytics in Looker last year. Building on this momentum, Conversational Analytics in Databases are also available in Preview. And so much more has happened — Google Cloud Conversational Analytics is available for more data, across more surfaces, with more enterprise controls, and greater capability than ever before. Let’s take a deeper look at the state of Conversational Analytics in the Google Data Cloud — what you can do with it, the benefits that it brings, and how to get started with it today. Query across multi-cloud and database workloads Conversational Analytics is now generally available for BigQuery and Looker, and in preview for AlloyDB, Cloud SQL, and Spanner. You can also analyze data stored in Lakehouse Managed Service tables, Apache Iceberg REST catalogs, and federated AWS S3 Unity Catalogs. Whether your data resides exclusively in Google Cloud or across multiple cloud providers, your agents can query it natively. For data practitioners, Conversational Analytics is integrated directly into BigQuery Studio, BigQuery Data Canvas, and Database Studio. For business teams, these conversational capabilities extend directly into Looker, Data Studio, and Gemini Enterprise. Data teams can publish Conversational Analytics agents created in BigQuery, Looker, AlloyDB, Spanner, and Cloud SQL directly into Gemini Enterprise, giving business leaders a centralized interface to query complex data safely. Our APIs and MCP tools let you embed Conversational Analytics wherever your business users work, like custom applications and multi-agent systems, or as slack chatbot that can answer questions across data sources, as we showed at Google Cloud Next. Enterprise security and governance controlsScaling generative AI to tens of thousands of users requires ironclad governance and transparent cost controls. Conversational Analytics includes Customer Managed Encryption Keys (CMEK), Private IP, and Virtual Private Cloud (VPC) controls. We guarantee Data Residency (DRZ) at rest and machine learning processing inside multi-region endpoints within the European Union and the United States, along with HIPAA compliance. For data access, role-based controls, including parameterized secure views in AlloyDB for PostgreSQL, help ensure users chatting with an agent only see data they are authorized to view, enforced down to row- and column-level permissions. Monitoring Conversational Analytics in BigQuery to track agent fleet health, active users, query volumes, and top knowledge sources. As usage grows, administrators need tools to manage costs, observe system health, and improve accuracy. You can configure native cost controls to define limits on maximum query sizes in bytes, and track usage through BigQuery query labels and Looker system activity logs. To maintain fleet visibility, agents can also export health, tool usage, latency, and token consumption metrics via OpenTelemetry (OTEL) standards. Integrated feedback loops allow administrators to review agent traces and user feedback, establishing a foundation for continuous evaluation and accuracy improvements over time. Grounded context through agent and data co-designWrapping a generic LLM around an enterprise database can sometimes lead to hallucinated logic. To minimize this, we co-designed Conversational Analytics agents alongside the data platforms they query. For instance, agents leverage Knowledge Catalog for data discovery, glossaries, and automated context enrichment like table joins and descriptions. BigQuery Graphs and Spanner Graphs allow agents to query structured and unstructured data across multi-hop relationships. Additionally, Looker’s semantic layer (LookML) grounds agent responses in centrally governed metric definitions, helping ensure answers remain deterministic rather than relying on guessed SQL joins. Grounding Conversational Analytics across Knowledge Catalog, BigQuery Graph, and Looker’s semantic model helps ensure deterministic, enterprise-governed responses. Conversational Analytics agents are also co-designed with the data they query. This means their tools are context-aware, to have the best understanding of the metadata. They also benefit from built-in capabilities like multimodal data querying using BigQuery object tables, operating over multimodal data with ai.search, ai.generate_embedding, ai.classify, ai.score and using ai.forecast and ai.detect_anomalies to use the TimesFM foundation for forecasting and anomaly detection.Additionally, ai.key_drivers performs automated contribution analysis to pinpoint exactly what is driving unexpected changes in your data. When integrated with Looker, these agents leverage the semantic layer to ground their responses in centrally governed, deterministic metrics. To avoid AI hallucinations, this API-first approach (using ‘Golden Queries’) ensures agents retrieve verified business logic rather than guessing at SQL joins. Looker additionally equips the agents to seamlessly navigate high-cardinality datasets with dynamic filtering, automatically enforce row-level security during the chat experience, and surface context-aware suggested questions. Proactive insights with Agentic Workflows Analytics is moving beyond reactive question-answering toward proactive intelligence. That is, instead of requiring users to ask the right question at the right time, Conversational Analytics agents can run multidimensional deep dives to analyze 10 to 20 contributing factors behind a change in a metric. With Agentic Workflows, now in preview, you can schedule automated reporting routines delivered directly into your chat workflow. Agents continuously run anomaly detection across key metrics, sending daily or weekly summaries straight to your team. Streaming anomaly detection can also launch an agent automatically the moment a key metric deviates from baseline thresholds. Running a multi-step deep dive in Conversational Analytics to automatically investigate complex data relationships across enterprise datasets. Flexible integration with APIs, SDKs, and MCP Conversational Analytics is available to developers and business users in their existing environments. The Conversational Analytics API includes native SDKs for Node.js, Java, Go, Python, PHP, Ruby, and .NET and keeps insights where the work happens. We are expanding how and where people use Conversational Analytics, starting with Looker Dashboards and Data Studio, as well as supporting publishing agents to Gemini Enterprise. You can also add Conversational Analytics to other multi-agent systems. Using the Agent Development Kit (ADK) and Model Context Protocol (MCP), you can integrate Conversational Analytics into custom applications, Slack bots, or multi-agent orchestrators. For example, a supply chain orchestrator agent can query a financial data agent to calculate the margin impact of a shipping delay in real time. Get started with Conversational Analytics Google Cloud Conversational Analytics unifies your data estate, security control plane, and developer APIs to deliver proactive data insights wherever your team works. Explore our Conversational Analytics documentation, review our quickstart repositories, and sign up to try our new previews today.

With cryptographically relevant quantum computers (CRQC) on the horizon, transitioning to quantum-safe digital signatures is critical to safeguarding long-term data integrity and authenticity. Organizations are steadily recognizing this urgency. For example, the U.S. government announced an update to the timelines by which departments and agencies must transition to quantum safe digital signatures. To help with the transition, we are announcing the general availability of our quantum-safe digital signatures (ML-DSA, SLH-DSA) and post-quantum key encapsulation (ML-KEM) in Google Cloud Key Management Service (Cloud KMS). The immediate challenge for your organization is functional: You need to sign massive data payloads without encountering the bandwidth and processing issues inherent with post-quantum cryptography (PQC). To proactively address these emerging threats and help you support compliance with regulatory obligations, you can use the suite of PQC digital signature algorithms available in Cloud KMS, which includes ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), featuring dedicated support for the efficient external-µ variants. PQC digital signature algorithms in Cloud KMS As standards and regulatory institutions are setting requirements and timelines for adopting quantum-safe algorithms, such as the National Security Agency’s CNSA 2.0, they’re underscoring the need for organizations to start their migration planning. To help you choose the specific security strength and signing method necessary for your applications, Cloud KMS gives you a broad selection of ML-DSA and SLH-DSA algorithms that are publicly available. Cloud KMS now supports the following PQC algorithms and variants: Algorithm Name NIST Security Category Variant Type Description SLH-DSA-SHA2-128s Level 1 Pure, Pre-hash Stateless Hash-Based Digital Signature for defense-in-depth ML-DSA-44 Level 2 Pure, External-µ High performance, Level 2 quantum security (equivalent to a collision search on SHA-256) ML-DSA-65 Level 3 Pure, External-µ Balance of security and performance, Level 3 quantum security (equivalent to an exhaustive key search on AES-192) ML-DSA-87 Level 5 Pure, External-µ Highest security for long-term data protection, Level 5 quantum security (equivalent to an exhaustive key search on AES-256) The need for pre-hash and external-µ variants The cryptographic elements used for digital signatures have a fixed or predictable size in memory. In contrast, the message being signed can range from a few bytes to massive files. This size disparity creates a major challenge when you use a separate, secure device, such as an HSM or a dedicated key management service. These systems are often optimized for security and key operations, but they have limited bandwidth and processing power, making it impractical or impossible to securely transmit and process extremely large messages in the security boundary for signing. Therefore, the application first processes the large message locally using a cryptographic hash function (such as SHA2 or SHAKE) to create a fixed-size, small digest that is around 32 bytes. The application then sends this small digest to the hardware security module (HSM) or key management service for the actual signing operation using the private key. NIST’s ML-DSA standard, FIPS 204 (Algorithm 7), uses an external-µ variant for its prehash functionality, which helps with this workflow. RFC 9881 Appendix D describes the details of external-µ. This method allows the application to calculate the digest (also called the message representative) externally and feed it into the pure ML-DSA signing algorithm. This offers the best of both worlds: The bandwidth efficiency of a pre-hash workflow, and full compatibility with pure ML-DSA verifiers. These external-µ variants also bind the public key mathematically to the message representative to achieve non-resignability, an important security property that prevents an attacker from manipulating the message representative in a way that verifies under a different, possibly attacker-controlled key. You can learn more details here, and explore the BoringSSL implementation for a practical example of handling external-µ. Google Cloud KMS now supports the pre-hash and external-µ variants. This enables high-performance, low-latency signing workflows that securely handles large payloads via external hashing, while integrating with pure verifiers. Getting started with PQC signatures in Cloud KMS Your applications can integrate these algorithms through the Cloud KMS API. Developers can use existing Cloud KMS capabilities to create, manage, and use PQC keys for signing operations. Detailed instructions and code samples are available in our KMS documentation to guide you through the process. The PQC road ahead The transition to a post-quantum cryptographic landscape is a collaborative journey. Adding PQC digital signatures in Google Cloud KMS is a significant milestone, helping you with your quantum-safe migration strategies. We will continue to update our services to incorporate future NIST standards and guidance, helping you maintain the security of your critical systems. We look forward to collaborating with you on your specific cryptographic needs, and we welcome your feedback. Related Article Announcing quantum-safe Key Encapsulation Mechanisms in Cloud KMS We’re supporting post-quantum Key Encapsulation Mechanisms in Cloud KMS, in preview, enabling customers to begin migrating to a post-quan… Read Article

As Best Buy expanded its use of Google Cloud for advanced analytics and AI, its technology teams faced two significant scaling challenges: Mitigating risk and managing administrative friction when syncing thousands of backend users from Microsoft Entra ID. The retailer solved both problems and paved the way for a massive cloud expansion by implementing Google Cloud’s Workforce Identity Federation. This direct approach allowed developers to access cloud resources securely using their existing Microsoft credentials without a separate identity store, giving technical leadership confidence that access remains strictly controlled, auditable, and manageable at scale. Replacing service accounts with direct federation Best Buy historically maintained complex synchronization pipelines to copy backend users from Entra ID to Google Cloud. Because the organization used Cloud Identity without a Google Workspace deployment, it needed a more direct approach. Previously, Best Buy’s Power BI integration with BigQuery relied on service account credentials. This pattern can work at a small scale, but quietly becomes a liability as your team grows. Manually rotating keys for service accounts meant tracking the credentials each team held, and accepting that every key was a potential security vulnerability. Service account keys created daily friction for the Best Buy security and platform teams, and the technical debt compounded as data access requirements grew more complex. To support tens of thousands of users, Best Buy modernized its identity architecture. The team adopted Workforce Identity Federation to federate existing Entra ID identities directly into Google Cloud. Now, when developers access BigQuery through Power BI, they authenticate as themselves using their existing Entra ID identity. They no longer need to rotate keys, worry about credentials exposed in chat messages, or guess who performed an action in the audit log. The architecture relies on two components working together: Entra ID handles authentication, Workforce Identity Federation brokers the trust relationship between Entra ID and Google Cloud. This federation is stateless on Google’s side. It validates tokens at the moment of access instead of syncing user records. Removing the service account key layer greatly reduces the credential management burden. Architecture The diagram below shows how identity flows from Entra ID through the Workforce Identity Federation to the services teams use at Best Buy. The key change from the previous approach is the removal of the service account key layer entirely; there is no credential to manage between Entra ID and Google Cloud. Identity flows from Entra ID through the Workforce Identity Federation to the services teams use at Best Buy Key implementation decisions When implementing this architecture, Best Buy made several important technical choices: Separate provisioning and SSO apps in Entra ID: The configuration follows the Entra ID provisioning and single sign-on (SSO) setup guide. You should separate the provisioning application from the SSO application in Entra ID. Running them as two distinct enterprise apps provides a cleaner separation of concerns; provisioning changes do not affect SSO configuration, and vice versa. Place the automation OU carefully: You need to place the Entra ID provisioning service account in a separate organizational unit (OU) and explicitly disable SSO for that OU. This prevents a bootstrapping problem: If you enforce SSO globally, the provisioning account cannot authenticate to set up the provisioning in the first place. Understand that syncless means stateless on Google’s side: Workforce Identity Federation does not create or maintain user records in Cloud Identity. It validates tokens at the moment of access. This makes the architecture viable for Best Buy’s target scale, because it eliminates synchronization lag, stale record cleanup, and separate provisioning pipelines. Secure authentication for developers For developers, the change was practically invisible. They authenticate once through their corporate Entra ID credentials, and access to BigQuery works automatically, whether through Power BI or direct API calls. The SSO experience matches everything else they access through their Microsoft identity. For the security and platform teams, the benefits are significant. The attack surface from credential management disappears. Audit logs now show individual users instead of shared service account identities, and you can revoke access quickly based on the enterprise identity lifecycle rather than waiting for manual key rotation. If you currently manage service account keys for developer access to Google Cloud, moving to Workforce Identity Federation is worth the effort. You gain significant security benefits, and the operational simplicity grows as your team expands. Best Buy is currently scaling this secure access to a broader workforce to power its future retail operations. Expanding Workforce Identity Federation support Google Cloud continues to make it easier for all organizations to bring their own identity providers. Recent updates simplify the setup for Ping Identity users and extend access to online billing accounts. Ping Identity integration: If you use Ping Identity, you can follow a new, dedicated setup guide to configure federation. This guide provides step-by-step instructions so you can securely connect your workforce to Google Cloud resources. Online billing support: Google Cloud now supports customers with online billing accounts. You can use Workforce Identity Federation for secure, syncless access without needing an enterprise billing agreement. Get started Google Cloud is committed to removing friction from cloud adoption and making it simpler for organizations to secure their environments. To explore these new capabilities and connect your organization’s identity provider, read more about how Workforce Identity Federation allows you to federate identities directly, and explore our supported Google Cloud services.

Summit gathers practitioners, contributors and engineers to advance open observability standards and practices Key Highlights SAN FRANCISCO, July 28, 2026—The Cloud Native Computing Foundation® (CNCF®), which builds sustainable ecosystems for cloud native software, today announced the…
Cookies
We use analytics cookies (Google Analytics) to improve this site. Accept to allow them. Privacy Policy