For people with serverless experience, how much of an issue is secrets management for you? I'm the founder of EnvKey[1], which is a saas/'serverless' secrets and config management solution that aims to be extremely simple to integrate and work with.
I have the idea that it could be particularly helpful in a serverless context, since I would imagine that configuration sprawl becomes an issue pretty quickly. That said, it's not an approach I have a lot of personal experience with, so I would love to hear thoughts on whether it's really a good fit!
Small company owner here (5 devs, no dedicated devops or ops people). It is a pain. We manage secrets with Ansible and Ansible Vault. When a key needs changing the process is very annoying. But at this point I never thought of it as a problem I would pay money for because it is still not painful enough.
Things would likely change if my company gets bigger, let’s say > 15 devs. Everybody can deploy the ansible playbooks right now but if the company gets bigger then I will have to worry about access control for different people. I may also have dedicated devops/ops people in which case I will want to limit normal developers’ access. I will worry about whether there is a process in place to ensure that keys always stay safe and are rotated whenever an employees leaves. etcetera.
Your product reminds me a lot of Launchdarkly, in that it solves a seemingly trivial problem (they help you manage feature flags), yet when you think of it in the context of a larger organization where people have to work together then there are suddenly lots of related problems that aren’t so trivially solved. Launchdarkly apparently managed to convince VCs to invest in them. You may want to look at them for inspiration. They have material posted on Heavybit.
I have looked at Vault but I have found integrating it with frameworks to be more challenging than I would like. There appears to be very few resouurces besides the official docs. Last time I checked it was not very clear how I would integrate it with Rails.
Thanks for laying out your thought process. I definitely see your point about it being an issue that gets much more painful as you grow. We do have a decent number of smaller teams using EnvKey so far, but my sense is that most were not replacing an Ansible/Ansible Vault-like setup, but instead saw it as a simple way to put any form of secrets management in place.
The comparison to LaunchDarkly is interesting. When first hearing about the idea of a feature flagging service, I do remember thinking "why does anyone need a service for this?" but as you say, the complexity grows very quickly.
I'm hoping to convince smaller teams that it's worthwhile for them to spend a few minutes and a few dollars up front to make secrets and configuration an area that is secure and 'just works' so they never have to worry about it again, but it's probably true that larger teams are a more natural fit.
The intentions are good, but right now it looks like an incoming traffic source (and since it's on HN's front page, it might have succeeded).
It enumerates the Top 10 Most Critical Security Risks, but doesn't explain what each one really means, gives examples of where and how they're exposed, or how to mitigate them. Things that OWASP does.
Now, you might say that it's just the beginning and they iterate. Fine, but without any detail on these Top 10, this document is not super useful.
It would have been better to wait until it had more "meat".
I agree. This would be market-y even if the actual resource wasn't hidden behind a signup page; most security firms have guidance for lambda security, which makes it odd to see a random firm declare the "top 10".
IMO this article is a waste of time. The issues outlined in the article like "increased attack surface" due to consuming data from HTTP APIs and message queues is nothing any other microservice-ish application isn't going to have to deal with. It's definitely not unique to serverless applications, and neither is anything else outlined in the article. And some of the assertions in the article such as a supposed inability to deploy a WAF in front of a serverless application are downright false.
Seems like you didn't really go through the document mate. What you are saying is exactly the opposite of what I saw. Each section actually has a "difference" between traditional and serverless apps. Moreover, if you read the beginning, they point out the reasons why WAFs are irrelevant...
Seems like you didn't really understand my comment mate. My point is that this link is blowing smoke and there are no substantial differences at the application layer.
There's no difference in security considerations when interacting with external resources at the application level. Either way you better have some form of auth and be sending credentials over TLS.
WAFs aren't irrelevant since from an external perspective there's no discernible difference between a request like
POST /login?user=root&password=' OR 1=1 --
being made to a handler running full-time on a dedicated web server or on-demand on AWS Lambda behind API Gateway.
So you yourself are only discussing HTTP. What about other types of serverless event triggers? do you know how to protect against injections in SNS? or what happens when you inject malicious input into data coming from S3? So yes, app security is app security, but there are nuances and pitfalls that are serverless specific...
You do realize that plenty of applications were handling events and files "serverless" was even a thing, right? Even in a cloud context, SNS and S3 long pre-date Lambda. Neither of those "pitfalls" are serverless specific.
In fact, Lambdas (and every other serverless platform I'm aware of) execute with the same isolation as EC2 instances in AWS. There are effectively no differences security-wise between code executing on an EC2 and code executing in Lambda. Any vulnerability in a Lambda function is also going to be a vulnerability in a traditional application hosted on EC2 and vice versa.
21 comments
[ 5.2 ms ] story [ 71.8 ms ] threadI have the idea that it could be particularly helpful in a serverless context, since I would imagine that configuration sprawl becomes an issue pretty quickly. That said, it's not an approach I have a lot of personal experience with, so I would love to hear thoughts on whether it's really a good fit!
1 - https:///www.envkey.com
Things would likely change if my company gets bigger, let’s say > 15 devs. Everybody can deploy the ansible playbooks right now but if the company gets bigger then I will have to worry about access control for different people. I may also have dedicated devops/ops people in which case I will want to limit normal developers’ access. I will worry about whether there is a process in place to ensure that keys always stay safe and are rotated whenever an employees leaves. etcetera.
Your product reminds me a lot of Launchdarkly, in that it solves a seemingly trivial problem (they help you manage feature flags), yet when you think of it in the context of a larger organization where people have to work together then there are suddenly lots of related problems that aren’t so trivially solved. Launchdarkly apparently managed to convince VCs to invest in them. You may want to look at them for inspiration. They have material posted on Heavybit.
[1] https://www.vaultproject.io/
[2] https://github.com/mozilla/sops/
Haven't tried sops, thanks for the link.
The comparison to LaunchDarkly is interesting. When first hearing about the idea of a feature flagging service, I do remember thinking "why does anyone need a service for this?" but as you say, the complexity grows very quickly.
I'm hoping to convince smaller teams that it's worthwhile for them to spend a few minutes and a few dollars up front to make secrets and configuration an area that is secure and 'just works' so they never have to worry about it again, but it's probably true that larger teams are a more natural fit.
It enumerates the Top 10 Most Critical Security Risks, but doesn't explain what each one really means, gives examples of where and how they're exposed, or how to mitigate them. Things that OWASP does.
Now, you might say that it's just the beginning and they iterate. Fine, but without any detail on these Top 10, this document is not super useful.
It would have been better to wait until it had more "meat".
There's no difference in security considerations when interacting with external resources at the application level. Either way you better have some form of auth and be sending credentials over TLS.
WAFs aren't irrelevant since from an external perspective there's no discernible difference between a request like
being made to a handler running full-time on a dedicated web server or on-demand on AWS Lambda behind API Gateway.In fact, Lambdas (and every other serverless platform I'm aware of) execute with the same isolation as EC2 instances in AWS. There are effectively no differences security-wise between code executing on an EC2 and code executing in Lambda. Any vulnerability in a Lambda function is also going to be a vulnerability in a traditional application hosted on EC2 and vice versa.