Audit Records

Keel exposes two distinct records: authorization decisions made by the control plane, and interactive sessions recorded by AWS. They answer different questions and require different grants.

Authorization decisions

keel audit decisions
keel audit decisions --outcome denied --since-hours 24
keel audit decisions --who [email protected]
keel audit decisions --all   # include routine reads

The account-wide log records who asked for which capability, its scope, and whether it was allowed or denied. Routine dashboard reads are hidden by default so refusals do not disappear inside polling noise. An operator needs the account-scoped audit capability; a partial view is not offered because it would look complete while omitting activity.

Recorded exec sessions

Enable cluster-level recording per environment:

audit:
  exec:
    record: true
    require_reason: true
    retention_days: 365
    # kms_key_id: alias/keel-exec-audit

Then read the sessions and one transcript:

keel audit sessions
keel audit transcript <stream>

AWS records every ECS Exec session on the cluster, including one opened outside Keel. require_reason is a separate client-side control: Keel can require keel exec --reason, but a direct AWS session supplies none and is still recorded.

The log group /keel/exec/<app>-<env> survives keel destroy. If it remains after a teardown, a later keel up adopts it before planning instead of attempting to create a duplicate.

What a transcript proves

A transcript is the terminal stream, not an infallible keystroke log. A process can suppress its own output, and session duration cannot be reconstructed from CloudWatch event times because ECS may upload a complete session as one event when it ends. CloudTrail and database statement logs remain the stronger record of effects.

On an operator session, transcript access uses the environment-scoped transcript capability. It is separate from application logs and from the account-wide audit capability.