Secure Cloud-Native Computing with Identity and Access Management

Cloud-native computing refers to creating and running software that leverages the unique benefits of cloud computing. Unlike traditional software built to run on a server, software developers architect cloud-native apps to run on cloud-based services. Since a 'decoupled' architecture forms the central theme of a cloud-native solution, Identity and Access Management (IAM) plays a vital role. Following a Zero Trust approach, a secure cloud-native application needs to authenticate and authorize every workload and component that forms the solution.

The core theme of cloud-native computing is building applications with the intent of running them on cloud services. This architectural shift from traditional application development means developers can leverage the advantages that come with cloud-based services. For instance, the cloud-native development philosophy incorporates the concepts of development and operations (DevOps), continuous integration and continuous delivery (CI/CD), microservices, and container-based architectures.

An excellent example of a cloud-native computing solution is Netflix. As the service offers its 207 million paid subscribers a complex set of features, it takes advantage of a host of cloud-based technologies. Due to its unique requirements to provide streaming services to an exponentially increasing user base, Netflix embarked on a cloud migration strategy in 2008. A significant database corruption was the catalyst as they realized the only way to keep providing quality services to an expanding subscriber base was to leverage the highly reliable, scalable, and distributed system the cloud offers. Moving Netflix to a cloud-native application also allowed the company to evolve rapidly and add new features. For instance, it uses artificial intelligence and machine learning algorithms to personalize its subscribers' user experience with recommendations and subtitle translation.

As its name suggests, a cloud-native app is an app built to run on cloud services exclusively. This capability allows developers to architect a decoupled solution where different application components run on the relevant cloud service. For instance, if we consider the Netflix example, the relevant user-facing capabilities would run on the cloud platform's web application services. Likewise, its network streaming would leverage the cloud platform's networking solutions, and its recommendation engine would use the machine learning service. This architecture differs from a traditional legacy application where all the logic and functionality run on managed infrastructure owned by the organization. With a cloud-native app, the various components run on highly available and scalable services that the cloud platform manages on your behalf.

A cloud-native architecture uses a cloud-first model to architect technology solutions. When formulating solutions, architects take a modular approach to leverage the various cloud services their application will consume. If we compare a cloud-native architecture to a traditional software application design, the differences lie with the infrastructure and services that host the application.

For instance, let's use the example of a regular web application that has a front-end, a business logic layer, and a database. In a traditional architecture, the developers will write code that will allow each of these components to run on a separate server or set of servers. With a cloud-native architecture, the architect will break down each application layer into a set of services. For example, the front-end may consist of a web page built with HTML, CSS, and JavaScript. It may also contain a collection of images and some functionality that enables a user to log in to the app. The logic layer may consist of several components that each process information or call external services. Using a cloud-native approach, the architect will build the solution and align each functional part with a relevant cloud service. Conversely, a traditional architecture will have all of these components residing on the same infrastructure managed by the organization.

The table below illustrates the differences between a cloud-native and a traditional architecture for the same type of app.

By building, deploying, and managing cloud-native apps, organizations can take advantage of the cloud's inherent benefits. For instance, cloud services give you the flexibility to only pay for services you consume. This computing model is far more cost-effective than hosting apps on traditional on-premise hardware. Furthermore, cloud services also provide on-demand elasticity allowing you to scale resources as demand from your users increases or decreases. For example, if your front-end needs more computing resources as the demand increases, cloud platforms allow you to quickly and easily add additional infrastructure. You could also automate this process to scale up resources when demand increases and scale them back down when it dissipates.

In addition to pay-per-use and elasticity, cloud services offer increased automation and simplify the change management process. Together these benefits allow organizations better management over complex solutions and give them the ability to deliver features and enhancements with improved velocity. For instance, since a cloud-native solution typically uses a modular decoupled architecture, making a change or adding a capability poses less risk than in a traditional application. It is also far more straightforward. As the part you are changing is decoupled from the rest of the application, you can apply the new code quickly and only test the points and features that integrate with it. In a traditional application, you need to refactor the code and then retest it end-to-end as it is architected as a single solution.

Because of the modular approach used in its architecture, a cloud-native app also allows for much greater flexibility. As you can deploy your app across a range of disparate services, technology lock-in is not a risk. For instance, you could deploy some of your code on a Java function app and other parts of your solution on a container running Python. You could even leverage a multi-cloud approach running some workloads on one provider's platform and others on a different cloud. This unlimited flexibility allows organizations the freedom to innovate and deploy new features quickly. By not being tied to a particular technology or platform, they can leverage any cloud service that meets their requirements.

Due to its decoupled nature, cloud-native computing requires a holistic, integrated approach to security. Architects that create cloud-native solutions need to consider securing every component and layer of their architecture. These components include the network, the various containers, microservices, and databases hosting the app and the data and the app itself. Ideally, the architect should configure the security for each component and layer so that each solution module can run in isolation with complete protection. One of the core benefits of a cloud-native app is its flexibility in that you can move various components to different services as the need arises. This flexibility dictates that you need to ensure the security of a particular element accompanies it to any platform.

Furthermore, as cloud-native computing relies on thousands of connections between standalone services with complex automation, the security architecture must secure the transit points. It needs to protect the data in transit as well as the endpoints. This complexity increases further if your application is also consuming data from other third-party cloud services. So, even though cloud-native has several advantages that make it the model for software development moving forward, securing it requires a fresh approach. Instead of securing the traditional perimeter as you would with legacy architecture, you need a decentralized security model that secures each component independently and the solution as a whole.

As mentioned, as each component works independently in a loosely coupled fashion, ensuring the confidentiality and integrity of your application and its data is vital. For example, every connection to or from a service needs authentication. Furthermore, once authenticated, the connecting service or component also requires authorization to ensure it can only access the relevant features it needs for its function.

Since the entire model of a cloud-native application is decentralized, the solution that manages its authentication and authorization should also be independent. A cloud-based, independent, IAM solution offers the features that can help you manage the security in a cloud-native architecture. It can centrally manage the identity of resources such as users or devices that are accessing the various components that together form your cloud-native solution.

From a DevOps perspective, a cloud-based, decentralized IAM solution can also help automate your cloud-native app's identity, authentication, and authorization services. For example, it can help you provision and deprovision users and offer a central console to manage every identity. Furthermore, with extensive reporting, your IAM solution can provide insights into the security of your cloud-native architecture, giving you more control and allowing you to mitigate any risks proactively.

An independent, decentralized IAM platform can also help you manage access to the cloud infrastructure you leverage to host your cloud-native app. For instance, OneLogin with AWS Control Tower integration gives architects the ability to easily govern their multi-role, multi-account AWS environment.

These examples illustrate that when it comes to securing your cloud-native app, there are multiple use cases where an IAM solution is invaluable, It can help you manage identities accessing your various cloud services, integrate into your solution as its identity provider, provide the relevant reporting, and even integrate with the cloud platform allowing you to manage access to the services hosting your app’s components.