New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create "obligatron" lambda #989
Conversation
0a4b778
to
eeddcee
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. Shall we walk @guardian/devx-security and @guardian/devx-reliability through these changes? And plan how to migrate any current obligations to this framework?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of minor, non-blocking comments.
|
||
const REQUIRED_TAGS = ['Stack', 'Stage', 'App', 'gu:repo'] as const; | ||
|
||
const isExemptResource = (resource: AwsResource): boolean => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a blocker for this PR, I wonder if switching on the resource would make it easier to assert those rules that apply to specific resource? For example:
switch (resourceType): {
case IAM_USER: {
return evaluateStandardTags && evaluateIamUserTags;
}
case EC2_AMI: {
return evaluateStandardTags && evaluateEc2AmiTags;
}
default: {
return evaluateStandardTags;
}
}
Going to merge this down as is as I want to get some code merged in and not keep updating this PR. There will likely be some changes once the ADR is published and theres a good chance we'll switch to pulling data from Security Hub instead of our AWS Resources view once we've finished figuring out how we turn that on for all accounts. |
What does this change?
Creates a new "obligatron" lambda which evaluates service-catalogue data and decides if its compliant with obligations.
Why?
This lays some of the groundwork for writing the business logic for some of the obligations the Ops team is working on (and maybe Security and Reliability too?).
Eventually this lambda should provide a framework for fetching data from Service Catalogue and saving it to a results table in a generic way so that when writing a new obligation the developer only has to worry about parsing the data, and not establish a DB connection or saving the results to a table.
In the short term this lambda will evaluate the Ops TAGGING obligation by fetching data from the aws_resources view, filtering out AWS managed resources, and validating them against our tagging schema.
How has it been verified?
Ran locally.