Update Discovery and Database Service IAM permission setup

The machinery for auto-configuring “connect” permissions is used for: RDS, RDS Proxy, Redshift, and ElastiCache.

For all of these, our auto-configuration tools like teleport db configure aws and teleport discovery bootstrap follow the same pattern:

setup a policy statement attached to <db service role> like this:

    {
        "Action": [
            "iam:PutRolePolicy",
            "iam:GetRolePolicy",
            "iam:DeleteRolePolicy"
        ],
        "Effect": "Allow",
        "Resource": "<db service role arn>",
        "Sid": "AllowDynamicDatabaseIAMAuth"
    }

attach a permissions boundary to <db service role> that limits, but does not grant, permissions. This is to prevent privilege escalation via PutRolePolicy. For example:
```
    {
        "Action": "rds-db:connect",
        "Effect": "Allow",
        "Resource": "*",
        "Sid": "AllowDatabaseIAMAuth"
    }
```

Then, the db service will monitor and modify its own permissions dynamically and add connect permission just in time for a connection.

This is complicated, grants the same effective permissions as the limits in the boundary policy, and makes a lot of customers ask questions. They ask questions because at first glance, granting an identity permissions to modify its own permissions is the same as granting all permissions in an AWS account. If the boundary policy is ever detached, then that is exactly what it means actually. The boundary policy also complicates permissions because we have to effectively name every permission twice: once in the permission policy and once in the permissions boundary.

We can eliminate the complicated permissions boundary, improve security posture, and simplify IAM setup for customers by eliminating the dynamic policy configuration. The db service works already without this dynamic policy setup by the way.

Therefore, this issue will be to track updates to our docs, auto configuration tools, and web ui integrations, with a focus to simplify IAM configuration for the Teleport Database Service and Teleport Discovery Service.

[x] eliminate iam:*User* permissions from docs
[ ] drop support for attaching to an IAM user in the bootstrap tools (breaking change)
[x] replace dynamic policy permissions with static permissions in the database service docs IAM reference
[x] add AWS IAM permissions reference page for Teleport Discovery Service
[x] update AWS OIDC integration to use static permissions
[ ] update bootstrap commands to use static permissions
[ ] drop support for dynamic permissions in Teleport Database Service (breaking change, requires a migration)

The migration for dynamic permissions is simple: in the next major release the database service will attempt to grant itself the required static permissions as a migration. In next major+1, database service will no longer monitor/update its own permissions.

https://github.com/gravitational/teleport/issues/16188
- eliminating dynamic permissions fixes this bug
https://github.com/gravitational/teleport/issues/25304
- simplify IAM setup, improve docs
https://github.com/gravitational/teleport/issues/41004
- improve AWS discovery setup UX

gravitational / teleport

Update Discovery and Database Service IAM permission setup #43829

Related