What Users and System Designers Must Learn from Google’s Best Practices for Password Management
5273
Of your peers have already read this article.
3:00 Minutes
The most insightful time you'll spend today!
Updated for 2021: This post includes updated best practices including the latest from Google’s Best Practices for Password Management whitepapers for both users and system designers.
Account management, authentication and password management can be tricky. Often, account management is a dark corner that isn’t a top priority for developers or product managers. The resulting experience often falls short of what some of your users would expect for data security and user experience.
Fortunately, Google Cloud brings several tools to help you make good decisions around the creation, secure handling and authentication of user accounts (in this context, anyone who identifies themselves to your system—customers or internal users). Whether you’re responsible for a website hosted in Google Kubernetes Engine, an API on Apigee, an app using Firebase, or other service with authenticated users, this post lays out the best practices to follow to ensure you have a safe, scalable, usable account authentication system.
1. Hash those passwords
My most important rule for account management is to safely store sensitive user information, including their password. You must treat this data as sacred and handle it appropriately.
Do not store plaintext passwords under any circumstances. Your service should instead store a cryptographically strong hash of the password that cannot be reversed—created with Argon2id, or Scrypt. The hash should be salted with a value unique to that specific login credential. Do not use deprecated hashing technologies such as MD5, SHA1 and under no circumstances should you use reversible encryption or try to invent your own hashing algorithm. Use a pepper that is not stored in the database to further protect the data in case of a breach. Consider the advantages of iteratively re-hashing the password multiple times.
Design your system assuming it will be compromised eventually. Ask yourself “If my database were exfiltrated today, would my users’ safety and security be in peril on my service or other services they use?” As well as “What can we do to mitigate the potential for damage in the event of a leak?”
Another point: If you could possibly produce a user’s password in plaintext at any time outside of immediately after them providing it to you, there’s a problem with your implementation.
If your system requires detection of near-duplicate passwords, such as changing “Password” to “pAssword1”, save the hashes of common variants you wish to ban with all letters normalized and converted to lowercase. This can be done when a password is created or upon successful login for pre-existing accounts. When the user creates a new password, generate the same type of variants and compare the hashes to those from the previous passwords. Use the same level of hashing security as with the actual password.
2. Allow for third-party identity providers if possible
Third-party identity providers enable you to rely on a trusted external service to authenticate a user’s identity. Google, Facebook, and Twitter are commonly used providers.
You can implement external identity providers alongside your existing internal authentication system using a platform such as Identity Platform. There are a number of benefits that come with Identity Platform, including simpler administration, a smaller attack surface, and a multi-platform SDK. We’ll touch on more benefits throughout this list.
3. Separate the concept of user identity and user account
Your users are not an email address. They’re not a phone number. They’re not even a unique username. Any of these authentication factors should be mutable without changing the content or personally identifiable information (PII) in the account. Your users are the multi-dimensional culmination of their unique, personalized data and experience within your service, not the sum of their credentials. A well-designed user management system has low coupling and high cohesion between different parts of a user’s profile.
Keeping the concepts of user account and credentials separate will greatly simplify the process of implementing third-party identity providers, allowing users to change their username, and linking multiple identities to a single user account. In practical terms, it may be helpful to have an abstract internal global identifier for every user and associate their profile and one or more sets of authentication datavia that ID as opposed to piling it all in a single record.
4. Allow multiple identities to link to a single user account
A user who authenticates to your service using their username and password one week might choose Google Sign-In the next without understanding that this could create a duplicate account. Similarly, a user may have very good reason to link multiple email addresses to your service. If you’ve properly separated user identity and authentication, it will be a simple process to link several authentication methods to a single user.
Your backend will need to account for the possibility that a user gets part or all the way through the signup process before they realize they’re using a new third-party identity not linked to their existing account in your system. This is most simply achieved by asking the user to provide a common identifying detail, such as email address, phone, or username. If that data matches an existing user in your system, require them to also authenticate with a known identity provider and link the new ID to their existing account.
5. Don’t block long or complex passwords
NIST publishes guidelines on password complexity and strength. Since you are (or will be very soon) using a strong cryptographic hash for password storage, a lot of problems are solved for you. Hashes will always produce a fixed-length output no matter the input length, so your users should be able to use passwords as long as they like. If you must cap password length, do so based on the limits of your infrastructure; often this is a matter of memory usage (memory used per login operation * potential concurrent logins per machine), or more likely—the maximum POST size allowable by your servers. We’re talking numbers from hundreds of KB to over 1MB. Seriously. Your application should already be hardened to prevent abuse from large inputs. This doesn’t create new opportunities for abuse if you employ controls to prevent credential stuffing and hash the input as soon as possible to free up memory.
Your hashed passwords will likely already consist of a small set of ASCII characters. If not, you can easily convert a binary hash to Base64. With that in mind, you should allow your users to use literally any characters they wish in their password. If someone wants a password made of Klingon, Emoji, and ASCII art with whitespace on both ends, you should have no technical reason to deny them. Just make sure to perform Unicode normalization to ensure cross-platform compatibility. See our system designers whitepaper (PDF) for more information on Unicode and supported characters in passwords.
Any user attempting to use an extreme password is probably following password best practices (PDF) including using a password manager, which allows the entry of complex passwords even on limited mobile device keyboards. If a user can input the string in the first place (i.e., the HTML specification for password input disallows line feed and carriage return), the password should be acceptable.
6. Don’t impose unreasonable rules for usernames
It’s not unreasonable for a site or service to require usernames longer than two or three characters, block hidden characters, and prevent whitespace at the beginning and end of a username. However, some sites go overboard with requirements such as a minimum length of eight characters or by blocking any characters outside of 7-bit ASCII letters and numbers.
A site with tight restrictions on usernames may offer some shortcuts to developers, but it does so at the expense of users and extreme cases will deter some users.
There are some cases where the best approach is to assign usernames. If that’s the case for your service, ensure the assigned username is user-friendly insofar as they need to recall and communicate it. Alphanumeric generated IDs should avoid visually ambiguous symbols such as “Il1O0.” You’re also advised to perform a dictionary scan on any randomly generated string to ensure there are no unintended messages embedded in the username. These same guidelines apply to auto-generated passwords.
7. Validate the user’s identity
If you ask a user for contact information, you should validate that contact as soon as possible. Send a validation code or link to the email address or phone number. Otherwise, users may make a typo in their contact info and then spend considerable time using your service only to find there is no account matching their info the next time they attempt login. These accounts are often orphaned and unrecoverable without manual intervention. Worse still, the contact info may belong to someone else, handing full control of the account to a third party.
8. Allow users to change their username
It’s surprisingly common in legacy systems or any platform that provides email accounts not to allow users to change their username. There are very good reasons not to automatically release usernames for reuse, but long-term users of your system will eventually come up with significant reasons to use a different username and they likely won’t want to create a new account.
You can honor your users’ desire to change their usernames by allowing aliases and letting your users choose the primary alias. You can apply any business rules you need on top of this functionality. Some orgs might limit the number of username changes per year or prevent a user from displaying or being contacted via anything but their primary username. Email address providers are advised to never re-issue email addresses, but they could alias an old email address to a new one. A progressive email address provider might even allow users to bring their own domain name and have any address they wish.
If you are working with a legacy architecture, this best practice can be very difficult to meet. Even companies like Google have technical hurdles that make this more difficult than it would seem. When designing new systems, make every effort to separate the concept of user identity and user account and allow multiple identities to link to a single user account and this will be a much smaller problem. Whether you are working on existing or greenfield code, choose the right rules for your organization with an emphasis on allowing your users to grow and change over time.
9. Let your users delete their accounts
A surprising number of services have no self-service means for a user to delete their account and associated PII. Depending on the nature of your service, this may or may not include public content they created such as posts and uploads. There are a number of good reasons for a user to close an account permanently and delete all their PII . These concerns need to be balanced against your user experience, security, and compliance needs. Many if not most systems operate under some sort of regulatory control (such as PCI or GDPR), which provides specific guidelines on data retention for at least some user data. A common solution to avoid compliance concerns and limit data breach potential is to let users schedule their account for automatic future deletion.
In some circumstances, you may be legally required to comply with a user’s request to delete their PII in a timely manner. You also greatly increase your exposure in the event of a data breach where the data from “closed” accounts is leaked.
10. Make a conscious decision on session length
An often overlooked aspect of security and authentication is session length. Google puts a lot of effort into ensuring users are who they say they are and will double-check based on certain events or behaviors. Users can take steps to increase their security even further.
Your service may have good reason to keep a session open indefinitely for non-critical analytics purposes, but there should be thresholds after which you ask for password, 2nd factor, or other user verification.
Consider how long a user should be able to be inactive before re-authenticating. Verify user identity in all active sessions if someone performs a password reset. Prompt for authentication or 2nd factor if a user changes core aspects of their profile or when they’re performing a sensitive action. Re-authenticate if the user’s location changes significantly in a short period of time. Consider whether it makes sense to disallow logging in from more than one device or location at a time.
When your service does expire a user session or requires re-authentication, prompt the user in real time or provide a mechanism to preserve any activity they have not saved since they were last authenticated. It’s very frustrating for a user to take a long time to fill out a form, only to find all their input has been lost and they must log in again.
11. Use 2-Step Verification
Consider the practical impact on a user of having their account stolen when choosing 2-Step Verification (also known as two-factor authentication, MFA, or 2FA) methods. Time-based one-time passwords (TOTP), email verification codes, or “magic links” are consumer-friendly and relatively secure. SMS 2FA auth has been deprecated by NIST due to multiple weaknesses, but it may be the most secure option your users will accept for what they consider a trivial service.
Offer the most secure 2FA auth you reasonably can. Hardware 2FA such as the Titan Security Key are ideal if feasible for your application. Even if a TOTP library is unavailable for your application, email verification or 2FA provided by third-party identity providers is a simple means to boost your security without great expense or effort. Just remember that your user accounts are only as secure as the weakest 2FA or account recovery method.
12. Make user IDs case-insensitive
Your users don’t care and may not even remember the exact case of their username. Usernames should be fully case-insensitive. It’s trivial to store usernames and email addresses in all lowercase and transform any input to lowercase before comparing. Make sure to specify a locale or employ Unicode normalization on any transformations.
Smartphones represent an ever-increasing percentage of user devices. Most of them offer autocorrect and automatic capitalization of plain-text fields. Preventing this behavior at the UI level might not be desirable or completely effective, and your service should be robust enough to handle an email address or username that was unintentionally auto-capitalized.
13. Build a secure auth system
If you’re using a service like Identity Platform, a lot of security concerns are handled for you automatically. However, your service will always need to be engineered properly to prevent abuse. Core considerations include implementing a password reset instead of password retrieval, detailed account activity logging, rate-limiting login attempts to prevent credential stuffing, locking out accounts after too many unsuccessful login attempts, and requiring two-factor authentication for unrecognized devices or accounts that have been idle for extended periods. There are many more aspects to a secure authentication system, so please see the further reading section below for links to more information.
Further reading
There are a number of excellent resources available to guide you through the process of developing, updating, or migrating your account and authentication management system. I recommend the following as a starting place:
- Our Modern Password Security for System Designers whitepaper (PDF)
- The related Modern password security for users whitepaper (PDF)
- NIST 800-063B covers Authentication and Lifecycle Management
- OWASP continually updates their Password Storage Cheat Sheet
- OWASP goes into even more detail with the Authentication Cheat Sheet
- Google Cloud Identity Platform is a multi-protocol customer identity and access management solution, with robust authentication features
- Google’s Firebase Authentication site has a rich library of guides, reference materials and sample code
Secret Manager: Keeping Your Organization’s Secrets Safer!
3282
Of your peers have already read this article.
2:00 Minutes
The most insightful time you'll spend today!
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.
Cloud and AI Paves the Future of Finance: Excerpts from FIA Boca 2022
6607
Of your peers have already read this article.
4:00 Minutes
The most insightful time you'll spend today!
Financial markets were among the first to adopt new technologies, and that has certainly been true of the derivatives markets, which were early adopters of electronic trading. Going forward, new capabilities will transform the way industry participants communicate, analyze, and trade.
I sat down with Google Cloud’s Phil Moyer and former SEC Commissioner, Troy Paredes, for a fireside chat at FIA Boca 2022 to discuss the future of markets and policy, the new technologies that are already paving the way for greater speed and transparency, and how cloud can help promote greater resiliency, performance, and security to enable the long-term vision for the market. The following is a summary of our discussion.
The current state of cloud technology
When it comes to technology adoption, we’re seeing the market and participants adopt cloud technologies, and increasingly, machine learning (ML) on a wider scale. Cloud technology allows for easier, faster, and much more secure experimentation with large datasets and ML.
A recent Google sponsored study by Coalition Greenwich (September, 2021) showed that more than 93% of trading systems, exchanges, and data providers are in some way providing services on the cloud. The same study, revealed that about 72% of the financial industry across the buy side and sell side, intend to consume public cloud-data based market data within the next 12 months.
Data-driven decision-making and risk management have always been, and continue to remain, the cornerstones of the financial markets. Over time, technology innovation has facilitated access to better insights from data, and therefore, better decision-making and the ability to manage risk. That expectation is now mainstream, and will continue to grow in sophistication.
The multi-phased technology trajectory
The movement of exchanges to the cloud will occur in a “crawl-walk-run” fashion, with low-hanging fruits the first to be picked in the near term while bigger, paradigmatic changes will occur over the medium and long term. Some organizations are starting all three stages simultaneously, understanding that each will move at an independent cadence.
The “crawl” phase is one in which foundations are built, starting with organizations moving data to the cloud and experimenting with some degree of analytics. It’s one of the most important phases because it’s where the opportunity to increase transparency and risk management takes shape.
In moving to the cloud, the infrastructure – which in the past relied on a combination of people, processes, and some technology – becomes the code that runs applications. This early phase is key to empowering organizations to shift to a cloud-based, agile-first operating model that makes it easier and more seamless to launch new products in the future, including by freeing up people and resources from IT management to more mission-focused work.
Establishing the cloud operating model simplifies the “walk” and “run” phases where compliance is more automated, latency-sensitive applications are more readily available, and the next generation of exchanges, market participants, and regulators is better prepared to meet future challenges.
The “walk” phase is where much of the innovation happens. Exchanges are making significant progress in leveraging foundational data decisions in the “crawl” phase and innovations in the cloud to improve settlement, clearing, risk management, collateral management, and compliance, and launch new products.
And finally, the “run” phase is where organizations will start to move the latency-sensitive markets to the cloud, as the markets increasingly will demand low-latency and high performance along with transparency and analytics to solve historical obstacles to market access.
Opportunities for both regulators and market participants
Any time significant technological change takes place, regulators explore its implications, particularly with respect to their ability to meet their regulatory objectives.
Increasingly, we are seeing technological change driving more opportunities for regulators and market participants alike. Such changes may also allow better protection of the marketplace, with greater integrity and transparency.
Over time, regulatory regimes – rules, regulations, statutes, interpretations, and guidance – will also adjust to new technologies, both benefiting the marketplace and advancing regulatory goals.
As one example, the cloud is increasing the ability to meet compliance obligations by allowing compliance to be built into transactions. Moreover, predicated on the vision of real-time regulatory reporting, and given the pace of technological change in the marketplace over the last several years, various regulators have been using more advanced analytics. This trend will continue to help them more effectively and efficiently meet their objectives, and monitor and meet the expectations they have for the entire market.
Machine learning’s role in the financial markets
Google Cloud’s head of AI and Industry Solutions, Andrew Moore, said that ML will be doing three key things for us in the next 10 years: giving us meaning, providing concierge services, and serving as a guardian. Extracting information that is critical to investor decision-making can be extremely important. With more data than ever, ML can increase the ability to process it while also becoming more accessible in the cloud and better supporting regulatory objectives.
The technology will likely manifest in trading and anti-money laundering activities as they relate market functions, as well as managing a wide variety of risks – supporting the interests of both investors and regulators in terms of decision-making, surveillance, and protections.
Rather than taking individuals out of the equation, the digitization of markets, assets, and guard rails combined with ML will allow people to focus their expertise in different ways to achieve key objectives.
Building the market foundation for the future
The goals of operational resiliency, security, and privacy will continue to be critical for building the market foundation for both participants and regulators. While technology promises to create advantages in concrete, tangible ways, it will be important to scrutinize potential risks and concerns.
Priority one for technology providers is to build an environment of trustless security, including encryption at motion and encryption at rest, ensuring that markets are operationally resilient while instilling confidence for any exchange that runs on top of that infrastructure. Multicloud architectures and approaches are likely also to be part of the solution for operational resilience.
Throughout time, liquidity has been the outcome of improved access, transparency, and security. Technology providers are responding by sharing both the responsibility for, and fate of, the markets of the future to build an efficient, faster, and more transparent and secure financial industry.
You can learn more about our approach in our newest white paper, Building the financial markets foundation for the future.
How Cloud Networks Enable CSPs to Deliver 5G
5125
Of your peers have already read this article.
3:00 Minutes
The most insightful time you'll spend today!
Communication services providers (CSPs) are experiencing a period of disruption. Overall revenue growth is decelerating and is projected to remain below 1 percent per year, following a trend that started even before the pandemic.1 At the same time, driven by the pandemic, data consumption in 2020 increased by 30 percent relative to 2019, with some operators even reporting increases of 60 percent.2
The combination of pressure on revenues with rising data traffic costs is forcing operators to innovate in three fundamental ways. First, operators are looking to establish new sources of revenue. Second, increased network utilization must be met with a reduction in network cost. And third, there is an opportunity to gain new customers by improving the customer experience.
Fortunately, 5G offers a path forward across each of these three areas. Concepts such as network slicing and private networks allow CSPs to offer differentiated network services to public sector and enterprise customers. The disaggregation of hardware and software allows new vendors with unique strengths to enter the market and to enable CSPs to build, deploy, and operate networks in fundamentally new ways. And the ability to place workloads at the edge permits CSPs to offer compelling experiences to consumers and businesses alike. In this blog, we will discuss how CSPs can create a solid foundation for their cloud networks.
Understanding telecommunications networks
First, it is useful to consider the way telecommunications networks were traditionally built. Initially, networks were built using physical network functions (PNFs) — appliances that used a tight combination of hardware and software to perform a specific function. PNFs offered the benefit of being purpose-built for a specific application, but they were inflexible and difficult to upgrade. As an example, deploying new features frequently required replacing the entire PNF, i.e., deploying a new hardware appliance.
The first step in improving deployment agility came with the concept of virtualized network functions (VNFs), software workloads designed to operate on commercial off-the-shelf (COTS) hardware. Rather than utilizing an integrated hardware and software appliance, VNFs disaggregated the hardware from the software. As such, it became possible to procure the hardware from one vendor and the software from another. It also became possible to separate the hardware and software upgrade cycles.
However, while VNFs offered advantages over PNFs, VNFs were still an intermediate step. First, they typically needed to be run within a virtual machine (VM), and as such required a hypervisor to interface between the host operating system (OS) and the guest OS inside the VM. The hypervisor consumed CPU cycles and added inefficiency. Second, the VNF itself was frequently designed as a monolithic function. This meant that while it was possible to upgrade the VNF separately from the hardware, such an upgrade, even for a feature that affected only a portion of the VNF, required deployment of the entire large VNF. This created risk and operational complexity, which in turn meant that upgrades were delayed just as they were with PNFs.
Creating the foundation for cloud networks
The trick to establishing your cloud based network resides in the challenge of moving from VNFs to containerized network functions (CNFs) — network functions organized as containers as a collection of small programs, each of which can be independently operated.
The concept of containers is not new. In fact, Google has been using containerized workloads for over 15 years. Kubernetes, which Google developed and open-sourced, is the world’s most popular container orchestration system, and is based on Borg, Google’s internal container management system.3 There are lots of benefits to using containers, but fundamentally, it frees developers from worrying about resource scheduling, interprocess communication, security, self-healing, load balancing, and many other tedious (but important!) tasks.
Consider just a couple examples of benefits that containerization brings to network functions. First, when upgrading the network function to implement new features, you no longer need to re-deploy the entire network function. Instead, you only need to re-deploy the containers that are affected by the upgrade. This improves developer velocity and reduces the risk of the upgrade because, rather than infrequent upgrades that each introduce substantial changes, you can now have frequent upgrades that each deploy small changes. Small changes are less risky because they are easier to understand and to roll back in case of anomaly. Incidentally, this also improves your security posture because it reduces the time between when a security vulnerability is discovered and when a patch is deployed.
Speaking of security, another example of the benefits that containerization brings to network functions is an automatic zero-trust security posture. In Kubernetes, the communication among microservices can be handled by a service mesh, which manages mundane aspects of inter-services communication such as retries in case of failure and providing observability into communication. It can also manage other essential aspects such as security. For example, Anthos Service Mesh, which is a fully-managed implementation of the open-source Istio service mesh (also co-developed by Google), includes the ability to authenticate and encrypt all communications using mutual TLS (mTLS) and to deploy fine-grained access control for each individual microservice.
Automation and orchestration for cloud networks
CNFs bring tremendous benefits, but they also bring challenges. In place of a relatively small number of network appliances, we now have a large number of containers, each of which requires configuration, management, and maintenance. In the past, many of these processes were accomplished using manual techniques, but this is impossible to accomplish economically and reliably at the scale required by CNFs.
Fortunately, there are cloud-native approaches to solving these challenges. First, consider the problem of autonomously deploying and maintaining CNFs. The ideal way is to use the concept of Configuration as Data. Unlike imperative techniques such as Infrastructure as Code, which provide a detailed description of a sequence of steps that need to be executed to achieve an objective, Configuration as Data is a declarative method whereby the user specifies the desired end state (i.e., the actual desired configuration) and relies on automated controllers to continuously drive the infrastructure to achieve that state. Kubernetes includes such automated controllers, and the great news is that this method can be used not just for infrastructure but also for the applications residing on top of it, including CNFs. This cloud-native technique frees you from the toil and associated risk of writing detailed configuration procedures, so you can focus on the business logic of your applications.
As another example, consider the problem of understanding your network performance, including anomaly detection, root cause analysis, and resolution. The cloud-native approach starts with creating a data platform where both infrastructure and CNF monitoring data can be ingested, regularized, processed, and stored. You can then correlate data sets against each other to detect anomalies, and with AI/ML techniques, you can even anticipate anomalies before they happen. AI/ML is likewise indispensable in gaining an understanding of why the anomaly is happening, i.e. performing root cause analysis, and automated closed-loop controllers can be developed to correct the problem, ideally before it even happens.
Architecting for the edge
The transition from VNFs to CNFs is a critical piece in addressing the challenge that CSPs face today, but it alone is not enough. CNFs need infrastructure to run on, and not all infrastructure is created equal.
Consider a typical 5G network. There are some functions, such as those associated with an access network, that need to be deployed at the edge. These functions require low latency, high throughput, or even a combination of the two. In 5G networks, examples of such functions include the radio unit (RU), distributed unit (DU), centralized unit (CU), and the user plane function (UPF). The first three are components of the radio access network (RAN), while the last is a component of the 5G core. At the same time, there are some other control plane functions such as the session management function (SMF) or the authentication and mobility management function (AMF) that do not have such tight latency and high throughput requirements and can thus be placed in a more centralized data center. Furthermore, consider an AI/ML use case where a particular model (perhaps for radio traffic steering) needs to run at the network edge because of its latency requirements. While the model itself needs to run at the edge, model training (i.e., generating the model coefficients) is frequently a compute-intensive exercise that is latency-insensitive and is thus more optimal to run in a public cloud region.
All of these use cases have one thing in common: they call for a hybrid deployment environment. Some applications must be deployed at the edge as close to the user as possible. Others can be deployed in a more centralized environment. Still others can be deployed in a public cloud region to take advantage of the large amount of compute and economies of scale available therein. Wouldn’t it be convenient — if not transformational — if you could use a single environment for deploying at the edge, in a private datacenter, and in public cloud, with a consistent set of security, lifecycle management, policy, and orchestration resources across all such locations? This is indeed what Google Distributed Cloud, enabled by Anthos, brings to the table.
With Google Distributed Cloud, you can architect a 5G network deployment such as the one shown below.
Business benefits of cloud networks
Beyond the technical benefits, consider the business benefits of such an architecture. First, by following the best practices of hardware and software disaggregation, it permits the CSP to procure the infrastructure and the network functions from different vendors, spurring competition among vendors. Second, each workload is placed in precisely the right location, enabling efficient utilization of hardware resources and offering compelling low-latency, high-throughput services to users. Third, because the architecture utilizes a common hybrid platform (Anthos), it makes it easy to move workloads across infrastructure locations. Fourth, the separation of workloads into microservices accelerates time-to-market when developing new features or applications, such as those enabling enterprise use cases. And finally, the container management platform supports the simultaneous deployment of both network functions and edge applications on the same infrastructure, allowing the operator to deploy new experiences such as AR/VR directly on bare metal as close to the user as possible.
The next generation cloud network is now
There is a lot more we could say, but perhaps the most important takeaway is that this architecture is not a future dream. It exists today, and Google is working with leading CSPs and network vendor partners to deploy it, helping them realize the promise of 5G to deliver new revenues, reduce operating costs, and enable new customer experiences.
To learn more, watch the video series on the cloudification of CSP networks.
Discover what’s happening at the edge: How CSPs Can Innovate at the Edge.
1.Statista, Forecast growth worldwide telecom services spending from 2019 to 2024
2 PricewaterhouseCoopers, Global entertainment and media outlook 2021-2025
3. Borg: The Predecessor to Kubernetes
3432
Of your peers have already watched this video.
1:30 Minutes
The most insightful time you'll spend today!
Lowe’s: Building a Centralized Price Management Solution
Watch how American retail company specializing in home improvement Lowe’s used Google Cloud to build a centralized price management solution. The company’s application development team leveraged Google Cloud to enable the improvement of their software development life cycle – from code development to CI/CD and monitoring.
Assuring Compliance in the Cloud: Paper by Google Cloud’s Office of the CISO
4911
Of your peers have already read this article.
1:30 Minutes
The most insightful time you'll spend today!
Cloud transformation and the adoption of modern DevOps technology presents both opportunities and challenges for IT compliance functions. With DevOps style application development, the feedback loop for developers and engineers is much tighter than with traditional application development pipelines, enabling speed and agility of application release cycles. While speedy CI/CD is a critical advantage of DevOps, it also shifts compliance left in the development timeline, and therefore puts pressure on the IT risk & compliance organization to modernize their approach to regulatory compliance as well. With the ongoing shift towards cloud technologies and DevOps, modernization of regulatory compliance is no longer optional for an IT compliance function
Compliance modernization is a broad mandate that spans the way the function is governed; the tools, technology, and analytics it uses; the number and nature of its connections to other parts of the business; verifiability and auditability of the controls’ evidence, the expectations assigned to it; and more.
Public cloud technology is becoming a core part of many industries today, and with this comes some potential risks such as cloud misconfigurations exposing intellectual property, loss of physical control of assets, skillset scarcity around cloud based security and compliance.
Given the constantly changing risk landscape, it is critical that regulations more closely align to address these risks. As regulations and risks evolve, the aim of a modern compliance function is to help an organization stay compliant as it goes through a digital transformation. As organizations go through digital transformation, IT compliance also needs to transform — via upgrading the technology stack, modifying the business processes and most importantly re-skilling people to become cloud aware.
Today we are releasing the new paper by Google Cloud’s Office of the CISO. In the paper we reveal a new approach for modernizing your compliance approach using modern approaches and Google Cloud toolsets. Your team can leverage the paper to add value to enterprises, both by charting a course to the safe use of cloud technology and by reducing risk through the use of the public cloud.
Read the paper “Assuring Compliance in the Cloud.”
Also, review these related resources:
- “Risk Governance of Digital Transformation in the Cloud“ paper
- “Making Compliance Cloud-native” (episode 14) with Zeal Somani
- Google Cloud Compliance resource center
- Our compliance blueprints: PCI DSS on GKE and GCP FedRAMP Blueprint
- Google Cloud security best practices center
More Relevant Stories for Your Company
A CIO’s Guide to the Cloud: Hybrid and Human Solutions to Avoid Trade-offs
What do CIOs and CTOs deliver for the company? If you said “technology,” that’s just the beginning. According to their research, McKinsey found that 85% of CIOs and CTOs interviewed in the spring of 2019 said they were essential for at least two of the three most common CEO priorities—revenue
How APIs Helped PWC Open New Revenue Streams Using Existing Data
PwC, one of the “Big Four” accounting firms, is well-known for professional services structured around auditing, insurance, tax, legal, and traditional management consulting. In Australia, the PwC Innovation and Ventures group has taken the global lead in building new, technology-based, turnkey lines of business outside of PwC’s traditional service areas.
Maximizing API Potential: A Look at 7 Prominent API Management Use Cases
Paper currency — which started gaining prominence in the 1600s — changed the face of global economics and ushered in a new era of international monetary regulation. The primary reason currency created such disruption was its ability to standardize the “medium of exchange”. APIs created a similar effect in the
How to Become a Hero by Metering and Understanding Your Utilization on GKE
It's hard to believe that GKE is already celebrating its fifth birthday. Over these last five years it's been inspiring to see what businesses have accomplished with Google Cloud and GKE—from powering multi-million QPS retail services, to helping a game publisher deploy 1700 times to production in the week of
