Consider preparing integrity protection for ADF resources

[yawn]

We are happy users of ADF for organisational / baseline (partially together with CT) as well as workload setups. One thing that is currently missing is integrity protection (in the form of an SCP) for the ADF infrastructure itself. Would this be interesting for the project as well?

I understand that (depending on the approach taken, specific resources / prefixes / maybe even tags if the coverage allows it) this might might not extend well to baselines being rolled out via regional / global but protecting the off-the-shelf ADF components would be enough for us initially (since we try to sail underneath the CT conventions for integrity protection for our customisations anyway).

Since #146 was closed - are you interested in a contribution here?

[bundyfx]

Hi @yawn

Indeed this is an area we could expand on, I think an SCP here that ships as part of ADF itself that handles locking down removal or alteration of base stacks would be a great addition.

[yawn]

A quick cat global.yml deployment/*.yml | grep Type | grep -Eo "AWS::[^\"']+" | cut -d ':' -f 3-5 | sort | uniq shows the following:

CodeBuild::Project
CodeCommit::Repository
CodePipeline::Pipeline
Events::Rule
IAM::ManagedPolicy
IAM::Policy
IAM::Role
KMS::Alias
KMS::Key
Lambda::LayerVersionPermission
Lambda::Permission
S3::Bucket
S3::BucketPolicy
SNS::Topic
SNS::TopicPolicy
SSM::Parameter
Serverless::Function
Serverless::LayerVersion
StepFunctions::StateMachine

A couple of initial remarks:

1. This will result (even when doing the usual minimisation steps) in quite a large SCP which is a problem due to the absurd SCP size limits but also when it comes to maintenance: doing anything else then blacklists with SCPs makes not much real-world sense but we need to keep the SCP in a form where we can react to new actions in the respective services. Currently there is no templating mechanism for SCPs in ADF so this might add some tooling overhead (e.g. a build script on top of policy_sentry).
2. Not all used services support authorization based on tags; since explicit ARNs are not useful for the SCP we want this means ... a naming schema (preferably one with small prefixes)? This would be a non-backwards compatible move and will also affect user pipelines.
3. Tiny / cosmetic: we probably want to change the naming schema of the root attached SCP.
4. I did a cursory list of the policies required for the Code* services and I believe it will take some consideration & coordination on what the policy should express since these service are on the higher quantitive end of action size.

I'll try to prepare an example SCP during the week but feedback on the points raised would be welcome.

[bundyfx]

Thanks @yawn - @thomasmcgannon + @kalleeh what are your thoughts on this? I'd like to get this into the 3.1 release with your guidance.

[yawn]

Please keep in mind that I based this evaluation on version 2.x.

[yawn]

Any update here on your internal planning? We can support here but I think we should consider changing naming conventions here to simplify the SCP. I'll do an ADF deploy today and double-check that my understanding is still up to (3.x) date.