AWS OIDC Integration: Deploy DB Service in a single click

[marcoandredinis]

This PR adds a new AWS OIDC Integration action: deploy DB and Discovery service in a single click.

This uses Amazon ECS to deploy a Database and a Discovery Service in a single click.
Please read lib/integrations/awsoidc.DeployDBService for more information.

Demo:

OneAgentDeploy.mp4

To use this new endpoint, the client (webapp) should send the following:
POST .../integrations/aws-oidc/<integrationname>/deployservice

{
    "deploymentMode": "database-service",
    "region": "<db region>",
    "subnetIds": ["<list>", "<of>", "<subnets>"],
    "taskRoleARN": "<aws role arn created in the flow>",
    "databaseAgentMatcherLabels": [{"name":"*", "value":"*"}]
}

• region and subnetIds comes from the response of listing databases
  subnetIds is from database[].aws.rds.subnets
• taskRoleArn should have a default value of TeleportDatabaseAccess (we should probably let the user change this, but not sure the design team is accounting for that
  This is the Role that they will be asked to create when executing the aws commands in aws cli or Amazon CloudShell
• databaseAgentMatcherLabels is the only required input from the user and can be defaulted to '*':'*' like we do for manual installation.

Fixes #25521

[public-teleport-github-review-bot]

@marcoandredinis - this PR will require admin approval to merge due to its size. Consider breaking it up into a series smaller changes.

[fspmarshall]

General suggestion: I think it would be good to decide on a standardized tag to apply to teleport-created aws resources. Ideally one that included the cluster name. That way a teleport cluster could determine which resources originate from itself. This would be very useful if we decide to implement cleanup helpers, or have configuration parameters that should only be applied to existing resources if the resource is "owned" by teleport (similar to how we currently update the builtin editor/auditor/etc roles only if they have a label indicating that they are teleport-generated).

[fspmarshall]

If we're going to establish a pattern of deploying ECS clusters to inject teleport agents, I think we should have a common configuration for all such clusters if possible. I.e. if I deploy 3 teleport agents to the same region/account I'd want them to all end up in the same cluster with one common set of configuration parameters that don't conflict with one another. That'll be easier to do if the cluster setup logic is designed to be generic from the beginning.

Would it be possible to make this its own standalone helper rather than being tightly coupled with DB service creation?

[marcoandredinis]

It's creating a fairly generic Cluster: name, tags, and FARGATE as a capacity provider
So, I don't think we are being coupled with the current creation.

I think we generalize the creation code-wise when we get a new use-case, doing it now, imo, feels premature.

[fspmarshall]

It's only premature if it's a lot of work. If it's relatively straightforward to break out, then it's just good planning!

Nbd either way, but if u leave as-is, maybe add a TODO suggesting reuse in the event we take up this pattern elsewhere. Don't want future folks overlooking this and leaving us with multiple parallel implementations.

[marcoandredinis]

General suggestion: I think it would be good to decide on a standardized tag to apply to teleport-created aws resources. Ideally one that included the cluster name. That way a teleport cluster could determine which resources originate from itself. This would be very useful if we decide to implement cleanup helpers, or have configuration parameters that should only be applied to existing resources if the resource is "owned" by teleport (similar to how we currently update the builtin editor/auditor/etc roles only if they have a label indicating that they are teleport-generated).

Yes, I was thinking about having deterministic names based on the cluster name.
But having a proper tag sounds better

What do you think about:

teleport-cluster: <cluster-name>

[fspmarshall]

What do you think about:

teleport-cluster: <cluster-name>

@marcoandredinis I don't know much about aws resource tagging best-practices, would it be appropriate to use a host-like namespace the way we do with kubernetes and teleport-internal labels? Ex:

teleport.dev/cluster: <cluster-name>

[marcoandredinis]

@fspmarshall Thank you for your review.

If you want to test this feature yourself, I can help you out 👍

[marcoandredinis]

@r0mant We talked about changing the ephemeral storage to use
However, it might get pricey to use the max available.
The current configuration is:
0.25 vCPU, 512MB of RAM and 20GB ("free" storage) disk = ~9$/month

Setting the disk space to 200GB, it will increase the total to ~23$/month
Technically, the change is simple:

	taskDefOut, err := clt.RegisterTaskDefinition(ctx, &ecs.RegisterTaskDefinitionInput{
		Cpu:    &taskCPU,
		Memory: &taskMem,
		EphemeralStorage: &ecsTypes.EphemeralStorage{
			// AWS charges ~ $0.000111 per GB per hour
			// https://aws.amazon.com/fargate/pricing/
			SizeInGiB: 200,
		},
       		// ...

Let me know if you still think we should increase.

[r0mant]

My main comment so far is I would like to design the "deploy service" API to be more generic where it just accepts the agent config it needs to run instead of being database agent specific.

[wadells]

What do you think about:

teleport-cluster: <cluster-name>

@marcoandredinis I don't know much about aws resource tagging best-practices, would it be appropriate to use a host-like namespace the way we do with kubernetes and teleport-internal labels? Ex:

teleport.dev/cluster: <cluster-name>

Chiming in from afar, we just had an RFD to standardize on some tags for internal use:

https://github.com/gravitational/cloud/blob/af5e8a829814f304df8705ecf4608c01dfe12e68/rfd/0071-Cloud-Resource-Tagging.md

Taking those ideas, they'd suggest:

teleport.dev/creator_type: teleport
teleport.dev/creator: <cluster-name>

cc @jof

[public-teleport-github-review-bot]

@marcoandredinis See the table below for backport results.

Branch	Result
branch/v13	Failed