Secret Manager is a Google Cloud service that provides a secure and convenient way to store API keys, passwords, certificates, and other sensitive data. It is the central place and single source of truth to manage, access, and audit secrets across Google Cloud. Since its launch, Secret Manager has helped secure millions of workloads and continues to provide industry-first features like replication policies and support for VPC perimeters. This blog post explores new Secret Manager capabilities and integrations that will help keep your secrets safer.

New tier, free of charge

No, you’re not dreaming – Secret Manager now has a tier that is free of charge! With this tier, each month per billing account you can have up to:

• 6 secret versions
• 3 rotation events
• 10,000 API calls

This enables you to experience the value of Secret Manager with minimal financial risk and pairs nicely with existing services that offer a free tier like Cloud Run and Cloud Functions. For existing Secret Manager customers, this change will go into effect next billing cycle. Learn more about the Secret Manager free tier in the documentation.

Increased SLA

To meet the growing availability and reliability requirements of our customers, the Secret Manager SLA is now 99.95%! With this update, Secret Manager guarantees that all valid requests will succeed 99.95% of the time. This means you can depend on Secret Manager for even your most critical workloads. Additional details are available in the updated Secret Manager SLA.

Geo-expansion

In addition to the free tier and increased SLA, Secret Manager is now available in all public Google Cloud regions! With Secret Manager’s replication policies, you can choose the specific regions in which to replicate your secret, which means you can store secret payloads in geographical proximity to your workloads or users to reduce latency. This is also very useful if you have legal or regulatory requirements to store data in a particular locality. For more information, check out the list of Secret Manager locations in the documentation.

Compliance certifications

For customers wishing to use Secret Manager to store and process regulated data, Secret Manager is validated for compliance use cases including ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3, PCI DSS, and HIPAA. Combined with the increased SLA and geographical availability, this makes Secret Manager suitable for use with regulated workloads.

Customer-Managed Encryption Keys (CMEK)

Secret Manager has always encrypted payloads in transit with TLS and at rest with AES-256. For customers that want additional control over the keys used to encrypt their secret payloads, Secret Manager now supports Customer-Managed Encryption Keys (CMEK). Secret Manager CMEK supports software-backed keys via Cloud KMS, hardware-backed keys via Cloud HSM, and even externally-managed keys via Cloud EKM. Learn how to enable CMEK support for Secret Manager in our tutorial.

Expiration and TTLs

While it was previously possible to expire access to a secret using IAM conditions, the underlying secret would continue to exist. Secret Manager now supports auto-expiring secrets which permanently deletes a secret at a specified timestamp or TTL. Since it is also possible to update a secret’s TTL, services can “lease” a secret and renew their lease on a periodic basis. If the service does not extend the lease by updating the TTL, the secret is automatically deleted.

Expiring secrets can be used in combination with IAM conditions to more safely expire secrets. For more information on expiring secrets and safety measures, see the guide on creating and managing expiring secrets.

Etags and server-side filtering

For customers that create or manage Secret Manager secrets via the API or an SDK, concurrency controls and performance are extremely important. This is why Secret Manager now supports Etags and server-side filtering! Etags help prevent concurrent modifications to the same secret by providing optimistic concurrency controls, while server-side filtering can dramatically reduce payload size and client-side computational overhead. Together, these enable stronger consistency guarantees and performance improvements to your applications. Learn more about Secret Manager Etags and Secret Manager server-side filtering in the documentation.

Code, build, run, deploy, monitor, and orchestrate

Secrets – like API keys, passwords, and certificates – are an integral part of most modern software applications. It is crucial that developers, operators, and security teams are empowered to build, operate, and observe software securely. That is why Secret Manager is now integrated with popular tools and technologies used throughout the application development lifecycle:

• Code – Software engineers can create and access secrets directly from their preferred IDEs with Cloud Code. In VS Code, IntelliJ, or the Cloud Shell Editor, developers can browse secrets and insert code snippets for access secrets, all from the comfort of their local IDE.
• Build – Release engineers can access secrets as part of CI builds using the Cloud Build Secret Manager integration. This could be used, for example, to authenticate to a Docker registry or communicate with the GitHub API. For customers that use other CI systems, there is also a GitHub Action for accessing Secret Manager secrets.
• Run (on serverless) – Developers can mount secrets to be available as environment variables or via the filesystem through the native Cloud Run Secret Manager integration. Since the secrets are resolved in Cloud Run’s control plane, developers can use this integration to avoid a tight coupling between their applications and Secret Manager to enable hybrid cloud deployments or better local development experiences.
• Run (on Kubernetes) – Developers can mount secrets from GKE, Anthos, or any Kubernetes cluster using the Secret Manager CSI driver. This vendor-agnostic driver exposes secrets via environment variables or the filesystem and enables hybrid cloud deployments using the same interface as other public cloud providers and HashiCorp Vault.
• Deploy – To complement the existing Secret Manager Terraform integration, operators can now manage Secret Manager via Kubernetes Config Connector (KCC). KCC allows operators to manage Google Cloud resources through Kubernetes and the familiar Kubernetes APIs.
• Monitor – With the Secret Manager Cloud Asset Inventory (CAIS) integration, security teams can understand secret usage across specific projects, folders, or the entire organization.
• Orchestrate – Secret Manager Event Notifications enable DevOps and security teams to subscribe to Pub/Sub topics for when secrets or secret versions are changed. This enables customers to create deeply-integrated workflows, such as creating a ServiceNow ticket when a new secret version is added. Additionally, Secret Manager Rotation Scheduling enables DevOps teams to build automatic rotation flows like the ones described in the rotation guide.

Best practices

The Secret Manager best practices guide ensures customers get the maximum security benefits from Secret Manager. Security is non-binary, and this guide covers nuanced topics like access controls, coding practices, and secret administration. While not an exhaustive list, the Secret Manager best practices guide answers some of the most common questions and concerns around using Secret Manager in production deployments.

Towards seamless security

Secrets management is an important part of every organization’s security toolkit. With Secret Manager, you can easily manage, audit, and access secrets like API keys and credentials across Google Cloud, Anthos, and on-premises. These new features and integrations make it easy to adopt Secret Manager whether you are a hobbyist working on a side project or a large enterprise with thousands of employees.

To get started, check out the Secret Manager documentation.

The Google Maps Platform Android SDK supports extensions for reactive programming, which helps you write code to handle asynchronous operations.

Write reactive and responsive mapping applications with Google Maps Platform

In mobile apps, asynchronous events can happen at any point in time: user touch events, waiting for network calls to complete, or receiving push notifications, to name a few. As an app developer, accounting for these events and composing them with other asynchronous events can be challenging. Reactive programming is an alternative to passing callbacks for different events and helps simplify the process of working with asynchronous events. In reactive programming, events are modeled as a stream, emitting items over time.

https://youtube.com/watch?v=1TmJvOZfBVQ%3Fenablejsapi%3D1%26

There are two libraries you can use to write reactive code: Kotlin Flows and RxJava. The next two videos show you how to use each one.

Writing reactive and responsive mapping applications using Kotlin

If you’re a Kotlin developer looking to use Coroutines and Flows, the KTX library allows you to use Kotlin Flows to receive events. The Maps KTX library includes extension functions that return Kotlin Flow objects, so you can listen to events in a reactive manner. Unlike suspending functions, which return a single value, Kotlin Flows can return several values over time. For example, you can use a Flow to receive camera event changes over time. To get started using Kotlin Flows in your app, include the Maps KTX library in the dependencies section in your build.gradle file.

https://youtube.com/watch?v=Cotx1ZmEYg8%3Fenablejsapi%3D1%26

Creating reactive maps on Android with RxJava

Integrate Google Maps Platform SDKs with popular Android library RxJava. RxJava is the Java implementation of Reactive Extensions, which is a library for composing asynchronous and event-based programs using observable sequences. One thing RxJava does is allows you to convert callback-based asynchronous code into a chain of transformations. Learn how this works and the other ways you can use RxJava in the third video in this series.

https://youtube.com/watch?v=AgGE7fAMrdA%3Fenablejsapi%3D1%26

​​We hope you learn more about reactive programming concepts to help you build responsive and reactive mobile apps in this three-part YouTube series. Have ideas for helpful videos you’d like to see on our channel? Leave a comment on any of our videos. And don’t forget to subscribe to our YouTube channel for the latest updates, tutorials, customer stories, and more.

For more information on Google Maps Platform, visit our website.

Earlier this year, we launched the Google Cloud skills challenge, which provides 30 days of free access to training to build your cloud knowledge and an opportunity to earn skill badges that showcase your Google Cloud competencies. Today, we’re adding a Native App Development track to the skills challenge, joining the Getting Started, Data Analytics, Kubernetes, Machine Learning (ML) and Artificial Intelligence (AI) tracks. 

The Native App Development track is designed for cloud developers who want to learn to build serverless web apps and Google Assistant applications on Google Cloud using Cloud Run and Firebase. Specifically, you’ll have an opportunity to earn three skill badges in the Native App Dev track: Serverless Firebase Development, Serverless Cloud Run Development, and Build Interactive Apps with Google Assistant. To earn a skill badge, you complete a series of hands-on labs and take a final assessment challenge lab to test your skills.

Here’s an overview of each badge.

Serverless Firebase Development

To earn this skill badge, you’ll learn how to build serverless web apps, import data into a serverless database, and build Google Assistant applications using Firebase, Google’s backend-as-service platform for creating mobile and web applications.

Serverless Cloud Run Development

For this badge, you’ll discover how to use Cloud Run, a fully managed serverless platform, to connect and leverage data stored in Cloud Storage. You’ll learn how to use Cloud Run to build a resilient, asynchronous system with Pub/Sub, build a REST API gateway as well as build and expose services. 

Build Interactive Apps with Google Assistant

To earn the final skills badge, you’ll build Google Assistant applications by creating a project in the Actions console, integrating Dialogflow, testing your action in the Actions simulator, and adding Cloud Translation API to your assistant application. 

Ready to jump into the skills challenge? Sign up here. 

You can also check out this quick video below to learn how to join the skills challenge.

Faced with changing customer behaviors and demands, tightening margins, and increasing threat from digital competitors, financial services institutions (FSIs) will need to meet customers where they are, open up their services, and establish new ways to monetize their products. Doing so will also enable them to build a better profile of their customers, and deliver more personalized user experiences and fast, convenient banking and payment services. Cloud technology plays a big role in this shift toward digital FSIs. 

In Asia, bank branches now account for just 12% to 21% of monthly transactions in the region, with customers turning to digital channels for routine transactions such as peer-to-peer transfers and bill payments, according to McKinsey&Company. Overall customer engagement has climbed from an average 12.7 to 14.9 transactions a month in Asia’s developed markets, and from 6 to 8.1 in emerging markets.¹

Fueled by growing smartphone adoption, the evolving customer behavior and momentum toward digital platforms have enabled digital-first players to snag a growing piece of the banking pie. 

McKinsey estimates that digital banking penetration has grown an average of 97% in Asia’s developed markets, and 52% in emerging markets, with between 30% and 50% of those that have yet to use digital banking likely to do so.

Consumers now are more than ready to make the switch to neobanks, or digital banks. In Singapore, 63% are open to banking with digital-only players, according to a Visa study. On what will entice them to do so, 63% point to bill payments while 56% will use neobank services to make payments at retail outlets. Furthermore, 54% prefer digital banks for the convenience they offer while 52% like the faster service.

Among those who are open to digital banks, 60% will move some services from their current bank to these new players even if the latter have no prior banking experience. One in five of respondents say they are willing to switch all services to a neobank.

The same is true for small and midsize businesses (SMBs) in Singapore. According to a separate survey by Visa, 88% of these companies will consider moving some services to digital banks.

Driven to do so by their frustration over a lack of quality corporate products and control of their banking experience, 55% of SMBs believe neobanks will help bring down overall banking costs. Another 54% say digital banks offer greater convenience, while 53% point to greater ease in paying bills online.

These stats should worry even established FSIs, especially those that have not done quite enough to open up their service ecosystems and drive innovation through APIs.

An API toward new revenue

While most banks have active APIs, the services that some of them currently provide are just functional; they’re the means to an end for partners to obtain their targeted products and services. Without knowing, consumers use these types of APIs indirectly by using their favorite applications every day—a payment processing API will enable them to purchase their lunch, while a loan application API will get them that dream home.

But while banks do not always own the customer journey, they still can find opportunities to sell their products via partners. Many leading banks are leveraging key technologies, such as API management, artificial intelligence (AI), and data analytics to embed digital banking into consumers’ everyday lives, including groceries, travel, entertainment, healthcare, and food delivery. 

When traditional banks open up their APIs to third parties offering broader services that pull in unique services into their own apps, they then become plugged into the broader customer journey. This helps boost usage of their services and embeds them in the overall customer experience. It also provides aggregated data that will help banks build richer consumer profiles, and deliver more personalized products and services.

APIs also create equal opportunities for smaller participants to be involved in the financial services ecosystem, potentially creating micro-segments that previously may not have existed. With insufficient demand within a closed system, to justify the provision of such services, some customers in these micro-segments have previously been left unserved. The APIs, which facilitate collaboration between the different micro-segments so they can be commercially viable, help assuage this problem. 

Some banks are also opening up APIs to allow access to datasets that enable businesses to trigger automated workflows and enhance their operational efficiencies. Others, such as Bank Rakyat Indonesia (Bank BRI) have generated new revenue by leveraging Google Cloud’s Apigee to manage their API lifecycle and identify new revenue opportunities.

Apigee’s monetization feature has helped Bank BRI realize $50 million in revenue and enabled the bank to define its pricing based on API calls and automatically bill based on usage.

In addition, the Indonesian bank uses the data analysis alongside Google Maps Platform to score its customer base of 75.5 million, and identify those who can be recruited as BRILink agents for underbanked areas. These agents are customers who maintain a minimum balance of $800 USD and score high on reliability.

The appointment of branchless agents via the Agent BRILink app has pushed the loan volume from the bank’s branchless business to $26 billion in 2018, up from $15 billion the year before.

How banks can get started with APIs

Clearly, there are new revenue opportunities for banks to leverage the data they already have. Here are some tips to help FSIs kickstart their API journey:

• Align with internal leadership growth initiatives. Leverage executive key performance indicators around growth and cost savings to foster a culture that offers APIs to micro-segmented markets with an eye on cultivating a healthy financial services ecosystem.
• Productize APIs with a strong value proposition. Starting with an API-first approach, stock the shelves of your API shop with new services and a strong inventory of APIs that will entice third parties (i.e., retailers, telcos, etc.) to start using them. This customer-first, outside-in approach will serve as a strong base to build on and enable the addition of more APIs as adoption grows.
• Actively nurture a developer community. A properly trained API manager will ensure constant contact with the developer community, and that partners are provided with case studies to help them identify viable use cases for your APIs.
• Leverage security as a strategic enabler. Security is a key enabler of the API economy, and most API security postures are defensive. By leveraging deep security tooling together with strong identification of developers, banks can better track information and data usage offensively. 

FSIs also need to avoid some common pitfalls, such as overlooking the need to continuously improve their APIs. If no one is using it, the API clearly is failing to provide any real value to third-party developers.

In addition, efforts should be made to market the APIs and let developers know what is available. A common mistake FSIs make is assuming their work is done once their APIs are released and neglecting the need to carry out community outreach and marketing to generate awareness about the APIs.

If you are interested in learning more about this topic, don’t miss our session at the Google Cloud Financial Services Summit on Embedded Finance: The Future of Banking.

^{1. McKinsey & Company. “Asia’s digital banking race: Giving customers what they want.” Global Banking Practice. April 2018.}

Chances are, when you think of Experian you think of a traditional credit bureau that provides credit reports. But Experian has transformed into a true technology and software provider. We gather, analyze, and process data in ways that other companies just can’t. Businesses use this data to make smarter decisions about credit and lending, as well as to prevent identity fraud and crime. We’re also able to use this data to help individuals take financial control of their own lives and access all kinds of financial services with products like Experian Boost.

Transforming data delivery, transforming the enterprise
A big part of our digital transformation has been based on our API program. We approached APIs with a concrete goal in mind. We knew exactly how we wanted to transform the business, and we had a set plan to achieve that. For us, this meant establishing an API center of excellence as a first step. It’s sole purpose was to enable the business units to create their APIs quickly and correctly, then apply them properly. We then went out to the business units one by one so that we could train them to build their APIs in a customer-friendly way. We taught them the entire API process of building, giving access to developers internally and externally.

This approach is fundamentally different from previous ones. As far back as the 1990s, our customers connected to us via software applications installed on their systems. As technologies evolved, our services to customers evolved, and we began supporting XML-based transactions and custom integrations with our partners. Some of these integrations actually included VPNs rather than going through HTTP connections. We did custom database schemas, one-off processes, and all kinds of custom development. 

This meant that we had a team just for our IT system processes. This team kept growing as Experian continued to acquire new companies. Each acquisition brought a new way of doing integrations and business. We had a real challenge in standardizing development practices, which led to a lot of isolated environments inside the company. We had disparate data repositories and non-standard client conductivity, which hampered innovation.

Responding to customer demand for APIs
When we first started, we had some concrete goals. We wanted to grow our ecosystem, develop a massive reach for transaction and content distribution, power a new business model, and drive innovation. Basically, we wanted to use APIs to transform our business into a platform, and we wanted to build an ecosystem that leveraged this API platform to develop new solutions. 

Our leadership also understood the importance of delivering information to our customers in the way they wanted to consume it. Our customers had told us that they didn’t want software, they just wanted access to the data—and APIs are the easiest, most secure way to grant that access. 

The Apigee API management platform as an enterprise solution
We knew we needed an API management platform to enable this step forward. In addition to the documentation and discoverability, we also wanted a place to create APIs fast, and where we could get visibility into usage and other metrics. The Apigee API management platform from Google Cloud offered all of this, and more. From the robust feature set to advanced security to the developer portal to analytics – Apigee provides us everything we need to run an enterprise-class API program.

Now that we have our API program up and running, integrations no longer take months. In some cases, it’s just a matter of minutes or seconds. Customers can simply look at our documentation on how to invoke APIs and begin consuming data in seconds. We started with this new model in our three largest markets: North America, the United Kingdom and Brazil. Later, we rolled it out to Singapore and Australia, while deploying an on-premises platform for some of our North American business units that needed to provide their APIs internally only. Next, we went to EMEA. At this point, we’ve deployed Apigee company-wide, giving us a flexible deployment model that maintains a centralized platform and processes.

We continue to evangelize the program today, and we recently conducted a workshop with the Apigee team to train our EMEA business unit and get them onboarded to the platform. They were able to start developing API proxies right away, and they’re set to go into production with as many as nine of them. We also went live with three developer portals, which we call API hubs, in North America, the United Kingdom, and Brazil. 

As we expand, we don’t want to keep building up different developer portals for each region because then we’re going to have too many. Alternatively, we plan to combine them into a single global developer portal that will allow users to select geographies of interest where they’ll be presented with relevant information.

Experian continues to evolve the types of products and services we offer. Thanks to Apigee, we have the flexibility, security, and technology to keep innovating and providing value to our business and our customers.