Cloud-native: New technology with old constructs.

Cloud-native: New technology, old constructs.

We need to find ways to efficiently secure cloud-native microservice environments. There is a need to provide every type of running process in an internal I.T  infrastructure with an intrinsic identity, to assert who we say we are. How do you prove who you are in a flexible manner regardless of what platform?  You need to give someone enough confidence to trust what you have just said to them. IP addresses are like home addresses, creating a physical identity for the house but not telling you who the occupants are. The more you know about the people living in the house the richer the identity you can give them. The richer the identity the more secure the connection.

Larger companies have evolved their authentication and security infrastructure to support internal service to service, server to server and server to service communications. Everything is an API call. There may only be a few public-facing API calls but there will be many internal API calls, such as user and route lookups. This will result in a scale that we have not seen before. Companies like Google and Netflix have realized there was a need to move beyond the things that most organizations do today.


Outdated: Network segmentation

Firstly, they rely on traditional network constructs such as network firewalls and routers to basically enforce authentication. If traffic wants to get from one IP segment to another IP segment, it passes through a layer 4 to layer 7 rule set filter then those endpoints should be allowed to talk to each other.

However, network segmentation is probably a bit too coarse-grained versus what is happening at the application layer. The application layer is going through major transformational changes. The changes to network security do not represent the application as much as the application should be represented. API gateways, web application firewalls (WAFs) and next-gen firewalls are all secondary when it comes to protecting microservices. They are just the first layer of defense. Every API call is HTTP/HTTPS so what good is a firewall anyway?

We have new technologies being protected by traditional means. The traditional security mechanism that was based on IP and 5-tuple can’t work in cloud-native microservice architecture, especially when there are lateral movements. Layer 4 is coupled with the network topology and it lacks the flexibility to support agile applications. Unless these traditional devices can follow the microservice workload, and follow the source/destination IP address, and source/destination port number around the cloud nothing will be effective. This is a design phase that will not happen. You need to bring the security to the microservice not the other way around.

Traditional security mechanisms for microservices are evaporating. The perimeter has changed and is now at the API layer. Every API presents a new attack surface which results in a gap. There is a gap that needs to be filled and there are only a few companies that do this. There are too few and we need more.


Outdated: Tokens and Keys

The other thing is the continued use of Tokens and Keys. They are hard-coded strings that are serving as a proxy for who you are. The problem is that the management of these items is difficult. For example, rotating and revoking them is challenging. This is compounded by the fact that we have to presume that the I.T organization infrastructure is going to become more horizontally scaled and dynamic in nature.

I think we can all agree that with the introduction of technologies such as containers, and serverless, we are going to arbitrarily see these things spin up and down because it’s more cost effective than to build and support tightly coupled monolithic applications. So the design pattern of enterprise I.T is moving forward and it makes the authentication problem more difficult. So we need to bring life a new initiative. We need a core and identity construct that supports the necessary design pattern when we are building for the future.


New identity-based mechanism

We need companies to recognize that a new identity-based mechanism is required. We have had the identity for human-centric authentication for decades. There are literally hundreds of companies built to do this. However, the scale of identity management of internal infrastructure is of an order of magnitude greater than it was with humans. That means that existing technology constructs and technologies such as Active Directory are not scalable and not built for this type of scale. This is where the opportunity arises – to build architectures that can match this scale.

Another thing that comes to mind when you look at these authentication frameworks when you think about identity and cryptography, it’s a bit of a black box, especially, for the newer organizations that don’t have the capacity and DNA to think about infrastructure at that layer.  For the organization, there is interest in a product that allows them to translate internal policies, that are no longer in the internal data center but in the cloud. We need a way to carry out the mappings to middleware public cloud using identity as the core service.

When everything has an atomic form of identity it can be used for a variety of other purposes as well. For example, you can use it to chain identity together, better debugging and tracing to name but a few.


About Matt Conran

Matt Conran has created 168 entries.

Leave a Reply