LearnLog
8:00am — CleanUp
Last time I was able to get the basics of custom resources in Fenrir working. Today I want to finish:
- Uploading a S3File with custom resource.
- Create Custom Resource S3ZipFile which will extract the ZIP file.
- Also clean up some of the code.
- Test out multi-account deploys with custom resources.
Using the Bifrost standard to build deployers provides a framework for building deployers that can work across AWS accounts by simply creating an assumable role in an AWS account. This make onboarding new accounts super easy. CloudFormation custom resources complicates this a bit because I want to keep this simple onboarding, so I don’t want to deploy a lambda.
9:30am — Validations and Tests
Cleaning up some validation code, fixed really annoying issue where coinbase-fenrir lambda was not logging because of missing IAM permissions. Writing tests as well.
11:00am — Old Client Code
After updating the validations, I have to read over some pretty old code and re-understand it. The Fenrir client code is not the prettiest as it is more an example implementation of how to interact with the Fenrir step function and used largely as a means of sandbox testing.
Fenrir pulls the Lambda code zips out of its Docker container, to provide a hermetic(-ish) build environment, and then uploads them to S3. So just extending that for arbitrary files now.
2:00pm — Boring Bits
This is the boring and necessary bit of programming. Not learning anything, just making sure it is all well tested and will actually work with a variety of inputs.
After getting the S3File resource working, it was actually not that much work to get the S3ZipFile resource to work as well. This resource will take an uploaded zip file and extract it to an S3 bucket with keys being prefixed by a value. To lower the amount of code, I am just using the S3File schema and validations for both. This might change later.
The cross account stuff will work from the Fenrir side. But I still have the question of how a CloudFormation stack in another account will be able to call a Lambda. It looks possible, but maybe some fun execution IAM policy is allowed. TBH I don’t know what permission I have given CloudFormation to call the lambda at the moment, but it works…
5:30pm — Will have to change later
Well shit. It is really annoying but I have a problem. I figured out how CloudFormation can call the Fenrir lambda, it is because the assumed role I call CloudFormation with has lambda:* perms, which work if it is in the same account. In another account I would have to allow the assumed role to invoke the lambda. This is not a good idea as it allows the bastion account access to other bastion accounts via the Fenrir Lambda.
I think I will have to go with the SNS solution from the AWS blog post.
Using a SNS topic will(?) provide a layer of strict validation before executing the Fenrir Lambda which means no arbitrary input. The reason I don’t like this solution is because it feels like a Rube Goldberg machine, which AWS seems to encourage building.
End
Overall a productive day, but nothing much learned other than my own mistakes.