4 ms·
I’m afk so will keep it brief :) The signing keys are stored in your config file and then uploaded with the lambdas. I think it’s reasonably secure if you trus
by gingerlime 7y ago
I’m afk so will keep it brief :)
The signing keys are stored in your config file and then uploaded with the lambdas. I think it’s reasonably secure if you trust AWS and the key is never transmitted.
Not too sure I understand the question about the lambdas. There are two at the moment (post and get) and they can be used by any cron job. You can also use your own lambdas and you don’t need to deploy the built in ones if you don’t want.
- mcintyre1994 7y agoThe signing keys thing you did (with HMAC) is nice, but not quite what I'm talking about - I'm thinking about secrets in headers/cookies for the requests you're making. An issue I have with my current approach that I think this would also have is if you didn't want them to be in plaintext. On the lambdas, I think from your blog post I understand what you're doing - you call the Lambda with an event which describes the task from Cloudwatch events. I didn't actually realise you could pass input from those events so that's what I was missing - because if you add an event as a trigger to a Lambda from the Lambda UI you can't give it a custom event as far as I can tell. I really like your approach, it's much cleaner. Currently I have a lambda per cron, and each has a list of tasks to run on that schedule defined in a file deployed as part of it. Having an event per cron/lambda/task combination as you do is much more flexible and much more understandable.
- gingerlime 7y agoThank you. I'm glad to hear. Perhaps best to discuss via a github issue if you have further questions or suggestions? I'm not entirely sure the concern over plaintext, if the request is over https and it's signed, but happy to explore options :)