3

I'm currently using AWS Lambda to run code that I don't have control over. As such, I want to make sure that the Lambda environment is sandboxed and does not have access to sensitive data. The default environment variables passed to a Lambda function are outlined here. The ones that I'd be worried about a user getting access to are:

AWS_ACCESS_KEY
AWS_ACCESS_KEY_ID
AWS_SECRET_KEY
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN
AWS_SECURITY_TOKEN

Is it possible to disable these environment variables? Currently I'm hiding these variables before executing the user's code, but it would be nice if I could flat out disable the environment variables.

Edit in response to comment:

I'm running untrusted code b/c I'm writing a game that teaches programming, and I want to use Lambda to execute the user's code. The permissions I've given to the Lambda function are minimal I think (AWSLambdaVPCAccessExecutionRole). Network access is restricted, however they could retrieve the results of their function as it's part of the game.

Edit two

I posted this question on the AWS forum b/c I don't think this is currently possible. The link is here.

Dehli
  • 5,950
  • 5
  • 29
  • 44
  • Those are temporary credentials associated with the execution role. It's not clear why you't use a role with more permissions than necessary ... nor, for that matter why you'd run untrusted code in Lambda. Can you clarify the use case? – Michael - sqlbot Mar 10 '17 at 23:45
  • Thanks for the response, @Michael-sqlbot. I updated my question. Let me know if you still need clarification! – Dehli Mar 11 '17 at 00:28
  • @Michael-sqlbot uh, Lambda is the **ideal** place to run untrusted code because you can precisely limit the time it can run and the amount of resources it uses. Where else would you run untrusted code? – idbehold Mar 12 '17 at 16:02
  • @idbehold that's a fair point, to a point, but without due caution it could access resources in your VPC or account with credentials in the environment, and do various nefarious things on the Internet that abuse reports would trace back to you. Really, though, the question on my mind was sort of an all-inclusive "why are you running untrusted code anywhere at all?" Generally speaking, running untrusted code is a recipe for trouble: what *can* be exploited *will* be exploited. I find that designs contemplating such functionality often also include an element of naïveté, though perhaps not here. – Michael - sqlbot Mar 12 '17 at 20:02
  • Thanks for the discussion! I guess there's currently not a way to do this. I'll post in the official forum with this as a suggestion. – Dehli Mar 13 '17 at 14:11
  • The default environment variables are no longer available at that link, here's another page for reference: https://gist.github.com/seeebiii/6d73b838dc4de74fd6323010e8a650b6 – Max Ivanov Apr 09 '21 at 10:38

1 Answers1

1

Unless something has changed recently, the only way to hide those variables is to explicitly remove them from the environment of your lambda function before invoking the user code, which I believe is what you're doing already.

Those variables are used by boto to provide access to AWS features using AWS SDK, and are what Lambda function users normally want to be in their environment. The role is whatever you configured for the function, so you could create a role that has no permissions (but then you wouldn't get any logging.) That is, if you use AWSLambdaBasicExecutionRole, the only permissions provided are logging to Cloudwatch, and you can remove even those permissions but you'll get no logging from Lambda. You could use this by default, and enable logging only when necessary for debugging.

Jeff Learman
  • 2,914
  • 1
  • 22
  • 31