On March 15th, the Go team announced Go 1.18 GA, the latest release of the Go programming language. The culmination of over a decade of design delivers the features our developers demanded: generics, fuzzing, and module workspaces. With this release, Go becomes the first major language to integrate fuzz testing into its core toolchain without using third-party support, further establishing Go as a preferred language for developing secure applications.

Go was created at Google in 2007, designed to help developers build fast, reliable, and secure software. Unlike traditional languages, Go was built for the modern multi-core computing world. Go has emerged as a modern language for developing cloud applications, services, and infrastructure. Today Go powers several of Google’s largest products, and is used by many customers to scale their businesses. Organizations big and small love Go and the community of Go developers, known as “gophers” has grown into a global network with over 2 million users worldwide.

Using the power of Go in the Cloud

When looking at the public repos, over 75% of CNCF projects including Kubernetes are written in Go and 10% of developers are writing in Go worldwide (as of May 2021). Google delivers high performance infrastructure to run key, cloud native, Open Source projects. Our modern cloud infrastructure is based on Kubernetes at its core and our strong support for Istio and Knative have formed the base of some of our leading services like Google Kubernetes Engine (GKE), our managed application platform with Anthos, Cloud Functions, and Cloud Run. Google uses Go extensively for a wide range of applications from our indexing platform that powers Google Search, to the server side optimizations that power Chrome’s 1B+ users, to the infrastructure on which Google cloud is built.

Release Highlights

With this new release of Go 1.18, Generics are the biggest change to Go since the language was created. Go developers told us that they feel that Go lacks critical features, with generics being the main missing piece. With Go 1.18, new and existing Go developers can take advantage of the productivity, performance, and maintenance benefits that generics can bring. We’ve already begun to see the new kinds of libraries and projects gophers are building with generics in its short beta period, and expect this creativity to grow as time goes on.

This Go release also brings native support for fuzzing. Fuzzing is a type of vulnerability testing that throws arbitrary data at a piece of software to expose unknown errors and is emerging as a common testing scheme in enterprise development. Go is now the first major language to provide fuzzing support with no third-party integrations necessary, allowing developers to start building secure software with minimal additional cost. Go’s innovative approach to fuzzing can provide not only security for the current code but also ongoing protection as code and dependencies evolve. With attacks on software becoming more common and complex, vulnerability detection can be a critical part of the enterprise development lifecycle, and Go’s fuzzing capabilities catch vulnerabilities earlier in the lifecycle.

Build securely using Go

At Google we are helping to make Open Source software secure. Open source software is a connective tissue for much of the online world. At Google, we’ve been working to raise awareness of the state of open source security and are committed to helping secure the software supply chain for organizations. Go has been designed to create secure applications, helping to minimize risk as much as possible. Go applications compile down to a single binary without local dependencies. It’s not uncommon to see an application built using only the standard library, or only a couple well-vetted Go dependencies. Go’s dependency management uses tamper-evident transparency log, with built in tooling that helps ensure your dependencies are what you can expect. Go has native encryption, which is used across much of the internet, including key components of Google. Go even supports distroless containers, where there are zero local dependencies to worry about. Google Cloud products like Cloud Build, for CI/CDand Artifact Registry, for container management, and have direct access to Go’s vulnerability database and can provide you instant warnings about security threats.

“At Google we are committed to helping to secure the online infrastructure and applications upon which the world depends. A critical aspect of this mission is being able to understand and verify the security of open source dependency chains. The 1.18 release of Go is an important step towards helping to ensure that developers are able to build secure applications, understand risk when vulnerabilities are discovered, and reduce the impact of cybersecurity attacks” said Eric Brewer, VP Infrastructure, Google Fellow

This launch is a significant milestone for Go that helps developers from around the world build more performant and secure applications that run on any infrastructure. For more information on this release and how to get started with Go, please visit.

Black Knight is a leading provider of technology, data, and analytics to the mortgage industry, catering to both large and mid-tier banks in the United States. Over the past few decades, we tended to manage customer integrations on a case-by-case basis. Whenever a bank needed to connect with a Black Knight app, we’d launch another integration project. Lather, rinse, repeat. Needless to say, this was inefficient; we knew we had to do something to centralize this process.

Building versus buying an API management platform
To start, we created some homegrown API solutions. Despite being largely successful with one of these solutions, we saw that technology advances were outpacing our capacity to update our solutions in-house. We knew we needed to move toward an API platform that would support RESTful architecture and that would fully enable mobile solutions. It also had to be extremely secure. Knowing how complicated such a platform would be to build ourselves, we decided that our developers were better off focusing on providing core solutions to Black Knight clients; engaging with an outside provider was the right way for us to advance our API strategy. 

After a lengthy proof-of-concept process, we went into production with the Apigee API Management Platform from Google Cloud in 2018. In our opinion, Apigee was the most complete, robust, technically sound and full-featured option from among all of the API management tools we evaluated. Its ease of use was the deciding factor for our developers, and the Apigee analytics capabilities provided considerable insight into the anatomy of an API call—something the other platforms we considered didn’t do as well. 

Choosing Apigee meant that we didn’t have to focus on developing and maintaining a tool or spend enormous amounts of money trying to keep up with security patching. For a large company like Black Knight, an API management tool is something we don’t want to spend a lot of time on. We know that Google Cloud devotes tremendous resources to it, and it would be difficult to replicate that in-house. 

Black Knight has more than 150 client-facing applications. Almost half of them now are built with APIs that are externally facing, and many of these apps use APIs that integrated with other Black Knight applications. Add to that the huge number of applications out there that come from clients and third-party vendors, and suddenly, we had a management challenge from an API perspective.

Driving cultural change
We came to Apigee with the goal of containing and empowering our huge ecosystem of APIs, customers, third parties, and internal users.  

Given Black Knight’s size, our developers and customers understandably each have different business goals, so getting everyone to come to a centralized platform is a great opportunity. My role is to help people consider other options so they can be open to the benefits that Apigee brings us.

Now that we’ve engaged with Apigee for over a year, we see two big benefits. First, the huge reduction in point-to-point integrations has produced tremendous efficiencies for us and our customers, who now get instant integration once they’ve been authorized for a particular API. Second, Apigee’s capacity for mobile enablement lets us satisfy our customers’ needs for secure mobile apps.  

Simplifying security
From a technical perspective, security is complicated for mobile apps. We’re often accessing sensitive information on a mobile device that can’t always be trusted. This kind of scenario requires us to implement a number of security precautions to help ensure confidential information remains protected.  

The Apigee API management platform addresses these needs in the simplest way possible. It solves complex problems related to security without having to deploy a new API proxy each time we need to support a particular mobile device upgrade. Our back-end applications remain protected because Apigee helps manage security, requests, access tokens, and authorizations. Today, our back-end applications work with Apigee to communicate with mobile devices or servers coming over the internet. 

Apigee has also enabled us to do a better job sharing a variety of APIs. The developer portal lets us stitch together APIs and get more creative about how we can innovate and build new solutions based on these collections of APIs. At this point, anybody that has a nondisclosure agreement with us can register for the developer portal. The nature of our business is such that we can’t just open up our APIs to anybody, but it’s available to our contracted third parties.

Our Apigee journey has been exciting, and we’re making great progress. I’m looking forward to what innovations we will come up with next, thanks to the way Apigee enables us to create, implement, and deliver.

When banks and other financial institutions make their products available via non-banks, we call that Embedded Finance. Think, for example, of a retailer offering financing for people buying goods; or a budgeting app gathering bank transactions to help you categorize and understand your spending patterns. The finance – the money management – has been embedded into the retailer or the budgeting experience.

This last example falls under the Data Exchange category of Embedded Finance , and it’s often also called Open Banking. In many countries this active data exchange is actually mandated by law, with specific Open Banking standards encoded into law for all financial institutions. As of this blog post, there are approximately 37 countries with such laws already in place or currently being worked on.

In an Embedded Finance scheme there are three main players: The financial institution offering their products and services, a third party provider (TPP) making use of those products or services, and an end user who is a customer of the financial institution and is interacting with the TPP.

The most important ingredient for these schemes is consumer trust. If a consumer does not trust that their data will be safely shared with a third party, and that they can easily understand the terms they have agreed to and stop sharing their data whenever they want to, consumers will simply not participate. When a consumer agrees for their data to be shared, this is called consent.

What components do I need for a successful Embedded Finance solution?

Banks’ products and services are made available to other parties via APIs, thus a fundamental component is an API Management platform. An API Management Platform lets you design, secure, analyze, and scale APIs anywhere with visibility and control.

Also, we need a component to manage consents given by end users. Consent Management refers not only to the capability of checking whether a certain action by a third party (eg: access an end user’s account balance) is valid according to the consent granted by the end user to that TPP,  but also the availability of tools for end users to check existing consents, modify them or revoke them, as well as tools for financial institutions to perform similar actions on behalf of their customers.

Finally, we need an Identity Platform capable of authenticating an end user and establishing their identity.

A Google Cloud based embedded finance solution uses Apigee as the API management platform, Identity Platform or your own identity platform of choice, and a consent management service (CMS).  Google Cloud has partnered with two leading providers in the consent management space: Clarip and CloudEntity.

How do these components work together?

The main roles and responsibilities of each of the three components are quite clear, but there is a certain degree of flexibility on how to orchestrate the interactions between the components, and which component performs which function when there is an overlap of functionality between them.

Google Cloud has tested the following interaction patterns:

• Interaction Pattern #1: Apigee as the main orchestrator

In this interaction pattern, Apigee interacts with both the consent management service and the identity platform, coordinating end user authentication with the identity platform, and authorization and consent with the consent management service. Apigee acts as the “broker” between users, their identity, and their consent.

• Interaction Pattern #2: The consent management service abstracts the identity platform.

In this case, the consent management service manages all the interactions with the identity management platform, and the identity platform acts as the “broker”. Apigee only interacts with the consent service.

The three components share a common pool of client apps and end users. One of the components is typically designated as the source of truth for these entities, while the other components that need to know about these entities synchronize that information from the source of truth. 

The identity platform is typically the source of truth for end user identities and the consent management component will synchronize that information by pulling it from the identity platform. 

The consent management service is the source of truth for user opt-in and current consent status. Apigee will either check with the service the validity of a consent every time a request comes through, or to make it more efficient, it will validate the main attributes of the consent based on information stored in Apigee. To maintain consistency, the consent management service should tell Apigee to invalidate any tokens associated with a consent when it is revoked via other means (for example, if an end user revoked consent from a consent dashboard).

For client apps, either Apigee or the consent management component can act as the source of truth, with the other component synchronizing the information. In the context of Open Banking in particular, standards often mandate that financial institutions support Dynamic Client Registration. This means having endpoints that new clients can use to register themselves as clients for the Open Banking APIs. In this case, the synchronization of clients can easily be incorporated into Dynamic Client Registration.

Let’s look now into more detail about how the three components interact. There are two user journeys that are particularly relevant:

Authentication/Authorization/Consent

This is the beginning of the typical consumer client journey, when an end user starts using a third party app that requires access to that user’s data. The third party app needs to authenticate itself, and request authorization to access the user’s data. This will trigger the authentication of the end user and consent granting: Consent granting being the process of, the user authorizing the operations the app will execute on their behalf, and establishing the list of accounts on which these operations will be performed. The authorization is represented by an access token, which the app will need to include in all subsequent requests.

This is quite a complex journey with many steps involved in order to make this as secure as possible. To make it easier to understand, we will simplify some of the steps (apologies in advance to you OIDC/FAPI experts out there!).

At a high level, these are the steps involved in this user journey:

1. End user starts using an app
2. The app requests permission to access user’s data
3. The identity platform (IdP) authenticates the end user
4. The consent management service obtains consent from end user
5. An access token is issued for the app, encapsulating the authorized permissions, accounts, etc. A refresh token is also issued – the access token normally has a short life (measured in minutes), but the app can use the refresh token, which typically lasts much longer (days or months), in order to obtain a new access token without the need of going through the end user authentication/authorization/consent process again.

The way these steps are orchestrated varies depending on the interaction pattern among the components.

Pattern #1: Apigee orchestrates all interactions
When the client requests permission, Apigee will record the request and then redirect the client app to the IdP login page. Once the end user logs in, the IdP will return an authorization code to the callback URL that Apigee registered in the IdP configuration.

Apigee will then redirect the client app to the Consent Management service, so that the consent form is displayed. Once the user grants consent, selects the desired permissions, and selects the accounts it will apply to, the Consent Management Service will update Apigee with the status of the consent, via a callback Apigee registered in the consent configuration.

Now that the end user has authenticated and granted consent, Apigee can now issue an authorization code, and associate all the necessary information, for instance, details about the consent, the authorization code issued by the Identity Platform (IdP), the identification of the end user in the IdP, etc. Apigee will return this authorization code to the client app via a callback endpoint that the app provided when registering with Apigee.

The app will then exchange the authorization code for an access token. Apigee will obtain an access token from the IdP, abd update the status of the consent before issuing an access token to the client.

Pattern #2: The Consent Management Service is the center of the Architecture
In Pattern #2, Apigee will only communicate with the Consent Management Service, which acts as an authorization server for the app and will also coordinate all interaction with the IdP.

When the client requests permission, Apigee will forward the request to the CMS. The CMS will record the request and then redirect the client app to the IdP login page. Once the end user logs in, the IdP will return an authorization code to the callback the CMS registered in the IdP configuration.

The CMS then displays the consent form. Once the user approves the consent and selects the desired permissions and accounts it will apply to, the Consent Management Service will return an authorization code to Apigee, via a callback Apigee registered in the CMS configuration.

From now on, the flow is the same as explained above. Apigee will issue an authorization code, associate all the necessary information and will return this authorization code to the client app via a callback endpoint. The app will then exchange the authorization code for an access token. Apigee will obtain an access token from the CMS, before issuing an access token to the client.

Let’s now look at the other relevant user journey:

Access shared data 

Once the third party app has been authorized, it will then start requesting that end user’s data. For instance, it may request the list of accounts or the balance of a particular account. 

When that request goes through, a series of checks need to be performed: Is this third party app still authorized? Has it been granted the right permission for the operation being requested? Is the account involved included in the list of accounts authorized by the end user? Apigee can perform all these checks by inspecting the access token presented by the third party app. 

There is, however, one other check which cannot be done simply by inspecting the token. Imagine for a moment that in-between the user granting consent and the app requesting the user’s data, the end user decided to revoke that consent. This could be done by other means than the app itself, for instance by checking all consents granted to all apps in a consent dashboard accessible via other channels such as an “Internet Banking” site. When the app requests the user data, the token is still valid, however the consent has already been revoked. Therefore, in this user journey, Apigee will check with the Consent Management service to check if the consent is still valid. This adds a bit of overhead, which can be minimized by other means. For instance, one popular optimization is to make sure that the Consent Management service asks Apigee to revoke any access or refresh tokens associated with a given consent when that consent is revoked via other channels. If that guardrail is in place, then Apigee can determine if a request should be allowed simply by validating the access token and using the consent information stored alongside the token.

The following diagram summarizes the interactions required between Apigee and the Consent Management component. The interaction is essentially the same in both interaction patterns.

What’s next?

In this article we have described how Apigee, a Consent Management service, and an Identity Platform are the fundamental ingredients of a successful and secure Embedded Finance solution. We have also looked at how these components interact with each other to keep user consent consistent and available. Both interaction patterns described are valid and have been proven to work. So which one may be right for you? The answer ultimately depends on your particular requirements, the choice of consent management service, and your choice of identity platform. As a rule of thumb, if you have multiple application experiences, identity systems, and sources of consent, an Apigee-centric architecture is a great solution. If you are looking at a Consent Management service in the context of an Open Banking implementation mandated by a centralized authority (eg: Open Banking Brazil, Consumer Data Standards in Australia), CloudEntity is a good choice for consent management, as their product is also Certified Financial-grade API (FAPI) OpenID Provider, with profiles for the various Open Banking standards. CloudEntity integrates with Apigee using Pattern #2. 

For more details on both Clarip and CloudEntity’s offerings and how their particular solution works with GCP please check:

• Clarip: Universal Consent Management Platform – GDPR
• CloudEntity: Certified OpenBanking  & Consent (UK, Brazil and Australia) at scale

For more details on Apigee API Management, see https://cloud.google.com/apigee

You can also learn about our solutions for retail banking or contact sales.

Mailjet allows companies to create, send, and track millions of emails to their customers and prospects around the world each month. The company’s offerings range from routing these emails to tailor-made tools that allow clients to design and send marketing campaigns with messages related to sales, user clubs, coupons and discounts, and promotions, as well as transactional emails such as purchase confirmations, shipping confirmations, e-tickets, or password resets.

“All of our services are accessible through programming interfaces. We use the same APIs for ourselves and for our customers. This is part of our unique selling point, which is to make life easier for developers and marketers,” explains François Fanuel, IT Operations Manager at Mailjet.

The company scrupulously monitors its service quality to help ensure that emails sent on behalf of its customers don’t trigger spam filters, and that they obtain the best possible open and click rates.

From hosting to the cloud

In its early years, Mailjet used hosted servers. This model had several disadvantages. It was impossible to instantly activate or deactivate computing power; the company could not be charged for actual, to-the-minute usage; and it lacked the flexibility to add disk space or scale servers in real time.

At the beginning of 2016, Mailjet decided to switch to the public cloud in order to improve technical and economic flexibility. “This two-year evolution required us to review our developments. If we use a virtual machine even for just one hour, our computer code must be able to support it in order to preserve the consistency and integrity of the data and processes,” says Fanuel.

“We needed a way to port our IP addresses to Google Compute Engine. In less than a month, the feature had been developed by Google engineers. This reactivity really impressed us and was definitely a deciding factor.”

—François Fanuel, IT Operations Manager, Mailjet

Mailjet and Google were already partners. The marketing and transactional email specialist is one of only three providers in the world, and the only one in Europe, accredited by Google to send bulk emails through Google Cloud Platform. The choice—based on three main factors—was obvious.

Financial and technical considerations

Factor 1: the right price proportionality. “We are able to activate Google Compute Engine virtual machines on demand, without needing to reserve these instances. While the machine remains active, a sliding-scale price is applied, which is particularly attractive to us,” explains Fanuel.

Factor 2: the quality and level of technical communication. Mailjet has direct access to Google Cloud Platform engineers when required. The company has its own IP addressing infrastructure, which is the foundation of its service quality. “We needed a way to port our IP addresses to Google Compute Engine. In less than a month, the feature had been developed by Google engineers. This reactivity really impressed us and was definitely a deciding factor.” Since then, via specific tunnels, Mailjet IP addresses have been ported directly into Google Compute Engine.

Factor 3: conformity to international data regulations. Mailjet is the only email service provider to be ISO 27001 certified and GDPR-ready, enabling the company to offer its clients the highest level of data security and privacy. Google Cloud Platform is also ISO 27001 certified, which was an important factor for Mailjet.

Power through minimalism

In mid-2016, Mailjet replaced its 30 or so email sending servers installed at a hosting company with smaller Google Compute Engine virtual machines, using the automatic load-balancing function. “Using smaller virtual machines—but more of them—optimized our computing power.” This precision mechanism accompanied an increase in activity for the company, with the number of emails sent doubling every year. As for the company’s some 300 TB of data, this is stored in Google Cloud Storage.

The flexibility and power of Google Cloud Platform helps ensure that Mailjet can adapt to peaks in activity that can reach up to 20 times the normal flow—our customers usually send their messages at the same times and during the same peak periods. “Previously, we had to reserve a lot of computing power with our hosting company, equivalent to 150 servers. Moving to an on-demand infrastructure means we can avoid paying a disproportionate fixed annual cost.”

Google Cloud Platform also provides Mailjet with the infrastructure needed to process events centrally, which facilitates technical support. A new analytics dashboard in the making will provide customers access to their campaigns’ key metrics in real time—a circulation report, open rates, and click-through rates, as well as invalid email addresses— regardless of the volume of emails at stake.

From distribution to development

Following routing operations, the development environment is currently being ported to Google Cloud Platform, and will eventually represent 100 virtual servers. “The addition of any new code is iteratively tested in Google Cloud Platform. We benefit from machines that are custom made for our needs, from machines with one core and 3 gigabytes of memory, up to machines with 64 cores.”

Mailjet uses the Google Cloud Interconnect virtual private network to tailor sending flows by geographical location. “For customers who only use our routing service, we will soon have worldwide load balancers. This will help ensure their API requests are received and their emails are sent to Europe and America from one single IP point, thus avoiding transatlantic latency issues.”

Mailjet also uses the Google Identity Aware Proxy authentication tool. All its employees around the world benefit from unique, more secure access, whether they use Google Sites intranets, or the development, or production environment. “Google Cloud Platform delivers on all the promises of a public cloud: service customization, real-time computing power adjustment during periods of high and low demand, and instant activation of computing resources. For us, it’s the best possible ratio between price, performance, availability, and quality,” concludes Fanuel.

Enterprise application teams need to manage more than just containers in their software supply chain. That’s why we created Artifact Registry, a fully-managed service with support for both container images and non-container artifacts.

Artifact Registry improves and extends upon the existing capabilities of Container Registry, such as customer-managed encryption keys, VPC-SC support, Pub/Sub notifications, and more, providing a foundation for major upgrades in security, scalability and control. While Container Registry is still available and will continue to be supported as a Google Enterprise API, going forward new features will only be available in Artifact Registry, and Container Registry will only receive critical security fixes.

Below, we’ll highlight the key improvements Artifact Registry provides over Container Registry, as well as the steps to start using it today.

A unified control plane for container, OS and language repositories

Artifact Registry includes more than just container images: as a developer, you can store multiple artifact formats, including OS packages for Debian and RPM, as well as language packages for popular languages like Python, Java, and Node. In addition, you can manage them all from a single, unified interface. 

A more granular permission model with Cloud IAM

Artifact Registry comes with fine-grained access control via Cloud IAM. Unlike Container Registry, this allows you to control access on a per-repository basis, rather than all images stored in a project. This enables you to scope permissions as granularly as possible, for example to specific regions or environments as necessary.

Repositories in the region of your choice

Artifact Registry supports the creation of regional repositories, which allows you to put your artifacts and data directly in the location that they’ll be used, allowing for higher availability and speed. In Container Registry, you’re limited to “multi-regions”: for example, the closest multi-region for Australia is Asia. However, with Artifact Registry’s regional support, you can create a repository directly in the Sydney data center.

A pricing model that respects your region

While Artifact Registry’s pricing is still based on a combination of network egress and storage usage, support for regional repositories means that you can choose in what region to host your container repositories. Although per unit storage costs are higher for Artifact Registry, optimizing the locations of your repositories to be hosted in the same region where they are used can result in cost savings, because any network traffic within the same region is not considered egress and is thus free.

Part of a secure supply chain

Artifact Registry was designed from the ground up to integrate into our suite of secure supply chain products. This means that it can optionally use Container Analysis to scan your container images for vulnerabilities as they’re uploaded to Artifact Registry, and works directly with Binary Authorization to secure your deployments.

We’re here to help you migrate

If you already use Container Registry, you can take advantage of all the current and upcoming features of container image storage with Artifact Registry by migrating to it. To help, we’ve prepared the following guides:

• Transitioning from Container Registry provides an overview of how to use Artifact Registry instead of Container Registry in a backwards-compatible way
• Copying images from Container Registry guide you to move container images from an existing repository to an Artifact Registry repository

If you’re currently hosting your container images with a third party, you can begin using Artifact Registry directly, by following the instructions in our guide, Migrating containers from a third-party registry, which shows you how to avoid rate limits on image pulls or third-party outages which can disrupt your builds and deployments.

And if you’re just getting started storing container images, you can begin using Artifact Registry as your image repository right away. To learn how, check out Artifact Registry quickstart for Docker, a guide to using Artifact Registry as a single location for managing private packages and Docker container images.

Join our community 

Our Artifact Registry communities are also great resources to help answer your questions and for guidance on best practices: 

• Ask questions on Stack Overflow using the google-artifact-registry tag
• Visit the Google Cloud Slack community and ask a question in the #artifact-registry channel. If you haven’t already joined the Slack community, use this form to sign up.