athena audit logs - support athena engine v2

[tobiaszheller]

Part of https://github.com/gravitational/teleport.e/issues/894
RFD: https://github.com/gravitational/teleport/blob/master/rfd/0118-scalable-audit-logs.md

Engine v3 cannot be used for now because it has some bug which prevents from querying audit logs via string which contains uuid (like uid or session_id). I am 80% sure that it worked before. There is issue on aws forum from 1 month ago.

Good thing is that there are not many differences that impacts us between v3 and v2. The only one is that v2 does support "?" placeholder only in where part. This PR address it so limit does not use query placeholder but raw value.

[rosstimothy]

LGTM but a couple questions:

1. How do we enforce that only Athena v2 is used? Is that a documentation only thing?
2. Is there anything we can do to detect if someone configured Athena v3 and throw a loud error to let users know the system will not work as configured?
3. If the Athena v3 bug is fixed do we need to make any changes to support v2 and v3?

[tobiaszheller]

• How do we enforce that only Athena v2 is used? Is that a documentation only thing?

You specify it when configuring workgroup in athena: https://docs.aws.amazon.com/athena/latest/ug/engine-versions-changing.html.

• Is there anything we can do to detect if someone configured Athena v3 and throw a loud error to let users know the system will not work as configured?

Yes, there is glue API call to check workgroup settings. If it won't be solved in v3 until we release support for self-hosted, I will add that warning.

• If the Athena v3 bug is fixed do we need to make any changes to support v2 and v3?

No, everything else works without any issues.

[rosstimothy]

Yes, there is glue API call to check workgroup settings. If it won't be solved in v3 until we release support for self-hosted, I will add that warning.

There is nothing preventing a self-hosted customer from using this today though. This lives in OSS and isn't gated by any license or feature flags.

[tobiaszheller]

Yes, there is glue API call to check workgroup settings. If it won't be solved in v3 until we release support for self-hosted, I will add that warning.

There is nothing preventing a self-hosted customer from using this today though. This lives in OSS and isn't gated by any license or feature flags.

It will mean that additional permission athena:GetWorkGroup is needed to teleport beside:

athena:StartQueryExecution
athena:StopQueryExecution
athena:GetQueryResults

do you think it's worth adding it or big indication in documentation is enough?

[rosstimothy]

Yes, there is glue API call to check workgroup settings. If it won't be solved in v3 until we release support for self-hosted, I will add that warning.

There is nothing preventing a self-hosted customer from using this today though. This lives in OSS and isn't gated by any license or feature flags.

It will mean that additional permission athena:GetWorkGroup is needed to teleport beside:

athena:StartQueryExecution
athena:StopQueryExecution
athena:GetQueryResults

do you think it's worth adding it or big indication in documentation is enough?

Documentation only might be fine. I'm more concerned about how we detect if something is misconfigured when someone inevitably ignores or does not read the docs.

[tobiaszheller]

Yes, there is glue API call to check workgroup settings. If it won't be solved in v3 until we release support for self-hosted, I will add that warning.

There is nothing preventing a self-hosted customer from using this today though. This lives in OSS and isn't gated by any license or feature flags.

It will mean that additional permission athena:GetWorkGroup is needed to teleport beside:

athena:StartQueryExecution
athena:StopQueryExecution
athena:GetQueryResults

do you think it's worth adding it or big indication in documentation is enough?

Documentation only might be fine. I'm more concerned about how we detect if something is misconfigured when someone inevitably ignores or does not read the docs.

queries with session_id will fail if someone is using v3 (until AWS fix it). I have added todo on my list to recheck if when adding docs to self hosted. We can then decide if we are adding that check or not. For now I will merge it as it is.

[public-teleport-github-review-bot]

@tobiaszheller See the table below for backport results.

Branch	Result
branch/v13	Create PR