tctl auth sign --format=db doesn't work via proxy

[r0mant]

Description

When trying to sign database certificate (for configuring self-hosted database) by invoking tctl auth sign remotely (which is the case of Teleport Cloud) users get this error:

➜  ~ tctl auth sign --format=db --host=db.example.com --out=server --ttl=8760h         
ERROR: this request can only be executed by a database service or an admin

The impersonation feature fixed this issue for issuing user certs, but generating a database certificate (i.e. certificate you configure your onprem Postgres/MySQL instance with) follows a different path:

https://github.com/gravitational/teleport/blob/v7.0.0-dev.9/lib/auth/auth_with_roles.go#L2549-L2556.

Instead of hardcoding built-in roles RoleDatabase and RoleAdmin to be able to call this API, we can change this to a resource-based approach and check if the caller's identity has "create" permissions for db_server resource which would mean they can generate the cert as well.

The change should be fully backwards compatible since both "admin" and "database" built-in roles already have create permission for database servers.

[klizhentas]

@r0mant I like the resource based approach, but wondering why do we connect certificate issue to a create resource, instead of using allow: db_logins as a reference (similarly to SSH and k8s)?

[r0mant]

@klizhentas So this is for the certificate that you use to configure your Postgres/MySQL instance with, not the certificate you use to connect to the database after tsh login, so my thinking was to tie this to the "create db_service" permission - since you're basically signing database cert to be able to configure a new self-hosted database instance and add it to the cluster so "create" verb seemed fitting ("db_service" is an already existing resource btw - used for CRUD database checks).

Another idea I had is to introduce a new verb like "register" (we had something similar in Gravity IIRC) and only allow permission to generate self-hosted db certs to roles that have "register" perm. for "db_service".

UPDATE: For the implementation in #7024 I actually decided that introducing a separate resource kind db_cert and checking "create" permission on it would be cleaner. This is also in-line with how permissions for host certificates generation are checked (host_cert kind) - which is conceptually similar to generating db certs.