[K9VULN-9361] Move Agentless Scanning cloudformation to a dedicated folder

[k3nz0]

What does this PR do?

Move Agentless Scanning cloudformation out of aws_quickstart/ to a dedicated folder.
We also now pin the agentless template link in main_extended.yaml.

[k3nz0]

Setting the bucket and pinning the version here on purpose.

Whenever the aws_agentless/version.txt gets updated, the aws_agentless/release.sh script will update this file too.

[k3nz0]

Pushed here:
https://datadog-cloudformation-template.s3.amazonaws.com/aws_agentless/v1.0.0/datadog_agentless_delegate_role.yaml

[mohamed-challal]

LGTM

[ktmq]

💭 why pin this instead of getting the latest version from aws_agentless/version.txt?

[ktmq]

also looks like the agentless release script can use a different bucket name, so I assume we'd want to keep <BUCKET_PLACEHOLDER>?

[k3nz0]

I added a placeholder for the version and updated the release script

[k3nz0]

I think we'd want to keep datadog-cloudformation-template which is another S3 bucket.

[diogocp]

I'm skeptical of this change because it seems to create bigger problems than it solves.

For most changes, we will still need to bump the quickstart version and release it. It's the same thing with more steps. We still need reviews from the AWS integrations team for those changes.

We will have two version numbers to keep track of—except with this change we would only track one; we would need to pass the quickstart version to the agentless template for the API to know exactly what is being deployed.

I think there are problems with the current release process. But as long as we want to integrate with quickstart, we still need to go through its release process. If we really want to make improvements, we have to improve quickstart too.

[diogocp]

I think this is outdated after your latest changes—as is the agentless release script.

[k3nz0]

I'm skeptical of this change because it seems to create bigger problems than it solves.

I agree this makes things a bit more complex. I actually hesitated before doing it.

Today, the issue is that aws_quickstart/ is getting polluted with Agentless-specific CloudFormation templates that don't necessarily belong to the core integration. For example, the CopySnapshot permissions template is purely an Agentless concern.

We also have more Agentless templates coming:

• A fix for missing autoscaling permissions
• A fix for missing SDS permissions
• CloudFormation StackSets for multi-account Agentless Scanning

To avoid confusion and establish clear ownership, I moved all Agentless Scanning templates into aws_agentless/. This seemed to make it easier to reason about.
The release scripts keep things synchronized. The quickstart script reads the Agentless version and injects it into main_extended.yaml, so the coupling is explicit and manageable.

I considered an alternative where we keep datadog_agentless_scanning.yaml, datadog_agentless_api_call.py, and datadog_agentless_delegate_role.yaml under aws_quickstart/ and put only the auxiliary Agentless templates in aws_agentless/.

I chose full separation so the answer to “where does my template live?” is always “aws_agentless/,” making the structure simpler to understand.