Aqua’s ‘Guardrails’ for Securing Serverless Containers, Functions
Serverless is being evaluated and adopted at a surprising rate — right up there with the rate at which containers were in 2016, the Cloud Foundry Foundation has reported.
And while the prospect of offloading infrastructure management to a third party remains an attractive proposition to many companies, few are likely to go all-in for serverless over other technologies, according to Aqua Security’s Rani Osnat. The use cases are different from that of containers, but security remains an issue for both.
“Containers and serverless — we don’t see them as competing. They’re complementary,” he said. “One or the other is not going to win. Companies are going to use both. So It makes sense for the security policy to be unified as well.”
The company recently released Aqua CSP v3.5, its cloud-native security platform, adding protection for serverless containers and serverless functions.
For serverless containers, such as such as AWS Fargate, the security issues mirror those of other containers — vulnerabilities in packages, images; embedded secrets meant to make life easier during testing, but forgotten and not removed later; poor configuration.
The lifespan of serverless functions is so brief — used in event-triggered functionality, middleware and batch processing scenarios – that the attack surface is smaller, so the risk is less, said Osnat, Aqua’s vice president of product marketing. However, permissions present a unique issue.
“When you set up a Lambda function, you can give it certain permissions based on the Amazon environment that runs it. Developers tend to be liberal with those functions because they don’t want anything disrupting the operation of those functions. An example would be access to S3 buckets, permitting API triggers. Because functions run so short a time — it could be milliseconds — traditional runtime controls, behavior monitoring are less important. More important to control what you’re actually deploying because your ability to actually enforce anything in runtime is limited. You’re basically seeing things in hindsight if you actually catch them,” he said.
Customers are basically interested in knowing that what they deploy is secure to begin with and knowing what kind of risk they’re exposed to, he said.
To that end, Aqua CSP v3.5 provides:
- Risk Assessment for Serverless functions: Checks functions for known vulnerabilities, embedded secrets (keys and tokens), and cloud permissions.
- Container Encryption: Aqua now makes it possible to encrypt the entire contents of a container image, decrypting it with a key when it is instantiated as a container.
- Greater Visibility through Workload Explorer of running workloads on Kubernetes and Docker environments.
- Contextual Runtime Policies
- Fine-Grained Administrative Access Control
“What we’re trying to do is give customers the ability to manage [both containers and serverless technologies] uniformly,” Osnat said.
The first step is giving them the tools to ensure their deployments are secure and done and in a way that’s acceptable to them from a risk profile. And keep tabs on what developers are doing.
“You need to have some guardrails. We provide those guardrails and allow customers to define what those guardrails are,” he said.
“We’re talking about companies that have hundreds of applications, different teams — whether it’s DevOps or cloud architecture teams, security teams, compliance teams — you have this complex weave of permissions and access you need to give people to control everything.
For controlling different applications, you’d need different trust levels, different compliance levels, and at the same time, you have reusable components.
“You might have MongoDB containers running on different applications, but they need to have different policies, depending on whether they’re internal applications or customer-facing applications; they need to have different policies depending on whether they’re PCI compliant. So you want to give them that granular control over where and how those policies are applied. Then who can view what and who can manage what on the administrative side?
“There are dozens of parameters we give the admins to control how these things behave. For instance, you can have differentiated policies based on what cluster, what namespace things are running on … Kubernetes, what registry they’re in, what image they’re based on, then all sorts of labels you apply.
Then you differentiate how people access it. Developers, for example, might get feedback on vulnerabilities so they can fix them, but they won’t be able to change the policy. Auditors will be able to get visibility and auditing reports, but they won’t be able to change the policy. Security guys might be able to change the policy, but they can’t change how Aqua is deployed on the cluster.
“It’s really a very fine-grained implementation of segregation of duties combined with contextual policies to control these multiple aspects of security,” he said.
The company will be adding more runtime security tools in the near future, he said, though in March it announced a set of runtime security controls branded as “MicroEnforcer” for environments such as Amazon’s Fargate and Microsoft’s Azure Container Instances (ACI).
In August, it open-sourced a tool called Kube-hunter to help search for security issues in Kubernetes clusters. In a blog post, technology evangelist Liz Rice likened it to automated penetration testing.
You can learn more about the challenges faced in monitoring serverless applications as well as their impact on enterprises’ security posture in The New Stack’s “Guide to Serverless Technologies” eBook.
Aqua Security and Cloud Foundry are sponsors of The New Stack.
Feature image via Pixabay.