Is there any way how I can make Lambda code not readable for users who purchased software license from me?
I am working on business model which involves Serverless framework, AWS and yearly license, and it would be a deal-breaker if anyone could download deployed code from S3 or from separate AWS services.
Best example is MoonMail service, but mine is in different market.
This is not really a Lambda issue, but more of an authentication issue. Your users should be authenticating in order to make requests (to any service, Lambda-based or otherwise) and at this time you confirm that they have paid their bill/subscription 
I know the A Cloud Guru guys use Auth0 to do their authentication - it sounds like it works well in a Serverless context. They have presented on their architecture at a number meetups and conferences so check that out (or you could just ask @johncmckim nicely 
).
@ivanderbu2 if you’re developing a SaaS product as @rowanu says an authentication service like Auth0 is great. It’s simply a matter of setting up a custom authorizer to protect your endpoints.
But, it sounds like your developing a software package that will be deployed into customer environments? Can you confirm if that is your use case? If so that’s very different to our use case and I’m not exactly sure how you should proceed.
@johncmckim yes, software will be deployed into customer environments. Once it is deployed they will have entire code, frontend and backend.
With Node and Python I’m 99% sure the answer will be no. The interpreter needs the source code to run. There are steps you can take to make this more difficult like using an obfuscator.
Java might offer more protection as you’re uploading a compiled .jar file. I’m not sure how easy these are to decompile into meaningful source.
Another option might be to use Go and Apex. Again, I’m not sure how easy it is to reverse the compiled code back into a usable source format.
@buggy then I think the only solution would be to roll updates on weekly/monthly level so it would make sense to have licensed software. Invoking some kind of obfuscator into lambda functions would be too costly.
I thought that there maybe some kind of permissions option, like in Unix systems where one user can not access other users files.
Who are you actually trying to stop from viewing the source?
It sounded like you’re selling a product to customers who self host using
their own AWS account and you don’t want those customers to access the code.
Can you provide a more detailed example of how you want this to work?
@buggy once user buys license and submit IAM creds, my system deploys entire infrastructure to their AWS account. So my system will posses one IAM user on their AWS account (for deployment and updates) but they will be admins cause it is their AWS account.
Is there some option to set permissions in that way so admin of AWS account can not access certain lambda functions? Sounds silly I know, but actually it would be a good thing for security, so they don’t mess up the system (or in this case copy/paste lambda code).
But on the other hand they would have access to creds of my IAM user, I see I will need to find other solution.
@ivanderbu2 I think the short answer is no. Your customers are the admins and have full control, as they should. Imagine a case were third-party code did something malicious (intentionally or not). The admins of the AWS account have the ultimate responsibility and should be able to disable applications deployed to their account.
If your main concern is your IP, you might be able to handle this through contracts. You should seek some legal advice on the best way to do that.
Deploying to custom sites is painful in a lot of different ways. Don’t do it unless your application absolutely requires it.
This is so true. I can’t agree enough.
Based on the other comments, I think @buggy has the closest thing you’re going to get as an answer - use a complied language. While I’m not putting this forward as a good idea, you could compile-in a check for the AWS account number that the code is running in, and only work in accounts that have been registered/paid for; While I’m sure it could be reverse-engineered, someone’s really got to want to do it.
In reality if you’ve got software good enough that people what to pirate, you’re bound to have a lot more people who can’t be bothered and will just pay you (i.e. so they can work on their actual problems, and get support from you, etc).
If you want 100% protection then you need to host the software on behalf or your client. It sounds like you don’t want to do the traditional SaaS model. You could try setting up an AWS account for each client, keep the credentials for yourself and pass the billing on to them.
The biggest problem with compiled languages will be the cold start time. We know if takes longer for Java to cold start than Javascript. I’m not sure about Go.
Why would this be too costly? Just make it part of the build process.
@buggy I meant each lambda function in that application is pretty light for execution and adding obfuscator will add more ms to execution. Actually I never done that in JS but from PHP experience I know it adds some overhead.
I agree with this, it’s better approach than playing cat and mouse game with the clients.
@ivanderbu2 Could you use consolidating billing to solve this problem? You would setup a new AWS account for each client then have them pay for it via consolidated billing. I’ve only recently started looking at this but I don’t think the consolidating billing account has access to your account.
@ivanderbu2 - I was reading the comments on this thread and it makes sense; however, I wanted to see if you ever found a solution to protecting the lambda code?
I understand that transparency is the best when deploying/running lambda functions in a client’s environment, but I do think as a SaaS offering that relies on Lambda, having a way to protect the source IP from theft would be useful.