Securely Asserting Identity (Role) From One Lambda To Another
Here's a simplified view of my situation:
I have two lambda functions (A and B). Function A invokes Function B for some of its processing.
I'm looking for some way to have Function B be capable of understanding that it is Function A making the call, in a secure and "most simple" way. In other words; Function B is exposed to the internet via an API Gateway, but how can I ensure that invocations are made by a trusted party?
My key-word here is "Simple"; of course, I could generate API keys and store those in Dynamo or whatever, but that feels needlessly complex when I'd be perfectly happy just knowing "Hey, this request was made by LambdaRole123". where LambdaRole123 is the role that Function A has assumed.
My initial thought was to generate STS tokens and send those along with the request to Function B, then just call a GetCallerIdentity with the token B receives. This, obviously, has some security concerns, but more tactically; Lambdas assume a role, and are provisioned with session tokens themselves, so those tokens can't be used to create new tokens.
My second thought was to try and replicate what I've seen the kubernetes AWS-IAM-Authenticator do; pre-sign a request to GetCallerIdentity, then send that pre-signed request. This feels like a better solution, but it seems surprisingly difficult to pull off with the Node SDK; its missing some of the methods I've come to expect from the Go AWS-SDK, like .Presign() method available on request.Request structure.
Any thoughts? Is there another way I'm missing to go about this? Or a relatively straight-forward way to get a pre-signed GetCallerIdentity URL, which would make (2) a viable option? Thanks!
Posted Oct 21, 2019, 9:45 PM UTC
I’m a little confused as it sounds like the design is a bit convoluted. Why can’t function A invoke function B directly, i.e., not using API gateway as an intermediary? Setting that up would be pretty simple, and you could configure access control with IAM without having to jump through hoops.
Yes this is the best route. Direct or there's all manner of triggers and orchestration within the AWS services. No need for A to go through https/API to talk to B if they're both lambda.