Demystifying PaaS security (part 2)

For a company wishing to transform its Information System by embracing the Public Cloud, integrating PaaS in a realistic way is by far the hardest bit if you put aside devSecOps organization, compliance and regulatory issues.

This has eaten a great deal of my time over the past 4 years. A time well spent, though, exploring caveats, finding and implementing prototypes and production grade mitigations, acknowledging that most of the risks couldn’t be covered by us - customers alone, and that the security foundations should be set by the Cloud providers themselves first.

A time also well spent connecting with the legal and engineering teams of Cloud providers who worked on the PaaS: these guys are very nice people always eager to get customer feedback and share ideas. Their mindset certainly explains how the public Cloud security has tremendously improved over the past couple of years, with the delivery of a tremendous quantity of security features.

PaaS integration 

In the first installment of this series, I argued how risks scenarios related to tenant isolation were eventually resolved into known, clearly defined territories in the latest offers of Azure and AWS, and how they were seemingly converging towards a de facto industrial standard with a residual risk that, unsurprisingly, depends on your risk appetite.

But compute PaaS security cannot be equated with siloed runtime execution. Obviously, compute instances do not run out of the blue, they have to interact with an ecosystem. The architecture foundations of this ecosystem is what I refer to as PaaS integration.

Securing PaaS integration

Several key areas must be covered in terms of risk management: here you might be in for a surprise because some very highly discussed topics (geo location, RGPD, secrets protection…) will not be mentioned here, while we will shed light on some seemingly obscure topics. Why? Things I wish to focus on today are areas where room for risk coverage, from a customer perspective, is currently poor at best.

Keep in mind that things are moving fast in the public Cloud world, most of the arguments might become obsolete within a few months (and I very much hope they will!)

Porosities of customer privacy

In a digitalized world, privacy has become an undisputed top concern for corporations and citizens. Until very recently, public Cloud customers had to make do with leased lines, private networks, encryption by default (at rest and in transit) and authentication to ensure their business privacy. That was pretty much all.

But under pressure Cloud providers came to realize that it was not enough, and they have tried to expand the scope of the privacy toolset. Still, privacy remains fragile today. There are some weak spots that I fancy calling 'porous confines'.

Porous endpoints

All PaaS endpoints (not only customer subnets) have to be privatized, and the truth is Cloud providers invested quite a lot of their devOps sprint bandwidth to inject PaaS endpoints into private networks over the recent couple of years. The main known and early example is load balancers which now come in external and internal flavors.

But there is still a lot to do in that field. Look at how Fargate, one of the latest AWS compute PaaS service, still exposes its endpoint on the Internet. Same for ACI, an also new Azure compute PaaS service. Same for ECR and ACR. The list is long...

There is also the side-issue of physical and financial scalability of private endpoints multiplication... A long story by itself.

Porous start points

What is a 'start point' will you ask? Well, simply the other end of an endpoint.

When a compute PaaS endpoint receives an incoming call from the Cloud provider (for example, an incoming troubleshooting remote session, an incoming request from a managed load balancer, ...), the service caller has better not use any IP within the Cloud provider private (or worse: public) IP range but rather use a dedicated private IP or a logical reference (a security group, a service tag, ...).

AWS had a head start with security groups (and IAM roles), but Azure has caught with service tags and more services injection into vnets. Still, many things could be done to get finer control over this porosity. The customers expects the same level of grain as they do in their LAN with their third parties, don't they?

Porous internet access

This has been a major concern because Cloud providers have taken a very long time to acknowledge that open internet access in compute PaaS was a deal breaker for many companies.

AWS answered the question for Lambda by providing a VpcExecutionRole where you have OSI level 7 control over egress flows, but other compute services like Fargate or Beanstalk or ECS remain elusive (this will probably change in the future) at levels 3 and 7 respectively. Azure solved the problem squarely this year for all its PaaS offerings with Azure firewall (see my dedicated article) up to layer 4. Layer 7 filtering is expected later this year or early 2019.

Customer security policies

Transitivity of control

This is certainly the most misunderstood risk related to PaaS integration, but it is quite simple to explain: most PaaS, especially compute PaaS, need one or more ancillary managed services to be fully functional. If you step back a little bit and look at service orchestration, it becomes clear that any PaaS belongs to a waterfall managed by the Cloud provider backend.

The problem statement is the following:

If you apply a security policy P1 to service S1 and a security policy P2 to service S2, and that if S1 uses S2 as an ancillary service, then you want P2 to apply when you instantiate S1.

Azure and AWS have very different approaches to tackle this problem. They both have pros and cons, and in my opinion none are really satisfactory at the moment.

• AWS relies heavily on its IAM engine, but while it is good a propagating fine-grain roles it was not designed for handling configuration management
• Azure counts on ARM templates hooked up on Azure policies and management groups, but this is still very much in preview.

So: lots of work and sweating ahead in both cases.

For the record, we can list a few common ancillary managed services:

? Object storage for image disks, various caches

? Load balancers

? Instrumentation and analytics services

? VM scale sets (or auto scaling groups)

? Docker registries

? Key Vaults (for both authentication and encryption)

? Internet gateways (to interact with third parties)

? Upstream API gateways for synchronous runtime execution

? Upstream event hubs for asynchronous runtime execution

? Security groups/tags

…

I'm not done with customer policies issues and there are other concepts to address, but this article is already longer than I wish so I will make a third part to carry on PaaS integration.

Let's keep posted!