Skip to content

Close out the retained CloudTrail audit session record #141

Open

Description

@alexeygrigorev

Close out the retained CloudTrail audit session record

Status: blocked — the research result and route decision are complete; one HUMAN must provide authentic sanitized expiry/revocation closure for the separate audit session, after which PM may close without any recollection
Tags: research, human, infra, data, P1
Depends on: None
Blocks: None — #140 and #143 are complete, #136 no longer depends on #141, and #166 is independent
Next owner: HUMAN owner of the original separate audit session, then PM for final closeout
Resume condition: the HUMAN posts sanitized confirmation backed by an authentic pre-existing issuance/expiry/revocation record that the original audit session expired or was revoked; do not call AWS, retry credentials, retrieve CloudTrail again, or reconstruct missing provenance
Closure condition: PM verifies that one session-closeout record, preserves the accepted insufficient verdict and deviations below, checks the final HUMAN criterion, and closes #141 only

Current outcome

The fixed CloudTrail Event History collection is complete and must not be rerun.

It found exactly one historical Sponsor CRM CreateTable event containing the historical DynamoDB TableId, but no exact CloudFormation StackId or canonical ownership tags. Separately authenticated deployment provenance contained the stack incarnation but not the TableId. The two records were not cryptographically linked.

Architecture and Security correctly classified the result as insufficient—not exact binding, conflict, or unavailable. #140 consumed that fail-closed result, rejected the historical-exception route, and selected the supported recovery route in #143.

That downstream route is now complete. #143 records that CloudFormation stack dataops-v1 owns logical DataOpsSponsorCrmTable, physical dataops-v1-sponsor-crm, resource status UPDATE_COMPLETE, with the table ACTIVE and empty. The old ownership-reset machinery was removed under #174.

Therefore #141 has no remaining product, infrastructure, ownership, migration, rollout, or #166 decision to make. It stays open only because the separate evidence-access session lacks authentic sanitized expiry/revocation closure.

Current OIDC and #166 boundary

Successful GitHub Actions deployments currently exchange GitHub OIDC identity for short-lived STS credentials. That evidence supports the CI credential boundary, but it is not provenance for the earlier separate phone audit role/session and must not be used to infer its exact issuance, policy, duration, principal, or expiry.

#166 uses its own exact HUMAN gates, backup/source/TableId evidence, repaired phase identities, and OIDC workflow. It must not:

Likewise, #141 does not wait for #166. Its sole remaining HUMAN closeout may occur independently at any time from authentic pre-existing session records.

Preserved sanitized evidence record

The private collection was reviewed with directory mode 0700 and file mode 0600. It contained 27 entries; all 22 manifested artifacts matched recorded byte sizes and SHA-256 digests. All nine JSON outputs parsed and no response retained an unconsumed continuation token. The two multi-page results contained 203 and 125 events, proving automatic pagination beyond page size 50.

Queries, counts, sizes, and public digests

  • Creation-source query, fixed 2026-07-12T21:15:00Z–2026-07-12T21:35:00Z in eu-west-1: 203 total/203 DynamoDB events; 442,330 bytes; SHA-256 6574da797b9a3ea8ab36341024103e6e426192d855923316e2632c22b084ff86.
  • CreateTable, fixed 2026-07-12T21:15:00Z–2026-07-31T06:11:00Z: 125 total/125 DynamoDB events; 372,629 bytes; SHA-256 59fe476f2ba7a6d04335493ef805ba4bc770078099da114bc9a6e76698cb1574.
  • TagResource, same interval: 3 total/2 DynamoDB events; 6,917 bytes; SHA-256 f4c1a21f10433139ab8a34e1f16ea54a4a6d026d6ea334c43122dee7edc11eb9.
  • UntagResource, DeleteTable, RestoreTableFromBackup, RestoreTableToPointInTime, CreateBackup, and UpdateTable: zero events each; each output 21 bytes; SHA-256 450e0ee55f895199f4b307725acfc2edd9d1a11aa63b457c0ed5aa221be0476f.
  • All nine stderr artifacts were empty; SHA-256 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 each.

Private parsing selected one target CreateTable event in both overlapping responses and confirmed identical selected bytes. No bounded target tag/delete/restore/recreate/backup/update event appeared. Negative history is corroboration only and never supplied the missing exact stack↔table pair.

Raw events, identities, account/resource identifiers, private locations, credentials, and operational evidence remain private.

PM disposition of procedural deviations

Accepted read-only operation deviation

A separate sts:GetCallerIdentity call occurred before the CloudTrail collection. The CloudTrail queries themselves used cloudtrail:LookupEvents and no mutation API occurred.

PM accepts this as a recorded, bounded, read-only process deviation for closure purposes:

  • it is explicitly disclosed rather than erased;
  • it did not broaden the CloudTrail query set or change the evidence bytes;
  • Architecture and Security accepted the evidence content only for the fail-closed insufficient verdict;
  • rerunning the collection would not add the missing StackId and is prohibited.

The operation inventory is LookupEvents plus one precollection GetCallerIdentity read, with zero mutation. It must never be restated as LookupEvents-only.

Missing provenance classified unmet

The retained bundle does not authentically prove all of:

  • the separate role's exact least-privilege policy and deploy-role isolation;
  • authoritative issuance time and configured session duration;
  • explicit retrieval time and principal/session provenance;
  • authoritative expiry/revocation.

The public reviews did confirm a separate phone sandbox role and the exact eu-west-1 query contract, but that is not a replacement for the missing authentic manifest fields.

PM accepts the policy/issuance/retrieval provenance fields as permanently unmet process metadata. Do not infer them from filesystem timestamps, current CI OIDC runs, general STS behavior, elapsed wall time, recollection, or memory. Their honest unmet classification does not alter the insufficient evidence verdict or reopen #140/#143.

Authoritative session expiry/revocation remains a separate security closure criterion and is not waived by this PM disposition.

Exact remaining HUMAN scope

The original session owner must use only an authentic record that already exists, such as:

  • an issuance/broker record containing the session's authoritative expiration;
  • an existing session record showing revocation;
  • an existing role/session management record that binds the exact private session and its expiry.

The HUMAN stores any raw record privately and posts only:

  • confirmation that it binds the exact original separate audit session;
  • record type, without identity/account/credential detail;
  • authoritative expiry or revocation UTC timestamp;
  • confirmation that the timestamp has passed or revocation completed;
  • confirmation that no AWS call, credential retry/reuse, CloudTrail recollection, policy change, or mutation was performed for closeout;
  • a collision-resistant digest of the private closeout record if appropriate.

Do not post credentials, session tokens, principal/account IDs, ARNs, private paths/links, raw broker records, policy documents, or CloudTrail content.

If no authentic record exists, say so. Do not reconstruct an expiry, test the credential, call GetCallerIdentity, inspect CloudTrail, or infer closure from current OIDC behavior. The issue remains blocked until PM and Security explicitly decide whether a separately groomed attestation-only closure is acceptable; this issue does not silently authorize that downgrade.

Acceptance criteria

Test scenarios

Authentic expiry or revocation record exists

Given an existing private record binds the original separate audit session
When the HUMAN posts only the bounded sanitized fields
Then PM may accept session closure without AWS access, recollection, or credential reuse

Authentic record is unavailable

Given no pre-existing record can prove expiry or revocation
When the HUMAN reports that absence
Then the issue remains blocked; no metadata is reconstructed and any attestation-only alternative requires separate PM/Security grooming

Current CI OIDC evidence is proposed

Given current deployments use GitHub OIDC and short-lived STS credentials
When that is offered as proof about the phone audit session
Then reject it because it is a different principal/session provenance chain

#166 asks to reuse the evidence

Given #166 is preparing or executing a Tasks cutover phase
When #141's Sponsor CloudTrail bundle is proposed as identity or ownership evidence
Then reject it and use only #166's reviewed exact backup/source/TableId/HUMAN gates

Recollection is proposed

Given the CloudTrail collection is complete, hashed, and insufficient
When a rerun is proposed only to repair metadata
Then stop; a new query requires a new authoritative source, new issue, and fresh Architecture/Security grooming

Out of scope

Activity

  1. added
    needs groomingRaw intake that needs PM grooming
    humanCode done or issue blocked on human verification
    researchInvestigation before implementation
    infraDeployment and infrastructure
    dataData model, migration, storage
    P1Important
    on Jul 31, 2026
  2. changed the title [-]Provide short-lived read-only CloudTrail access for Sponsor table provenance[/-] [+]Provide one short-lived CloudTrail Event History audit session[/+] on Jul 31, 2026
  3. alexeygrigorev commented on Jul 31, 2026

    @alexeygrigorev
    MemberAuthor

    ARCHITECTURE EVIDENCE REVIEW — CLASSIFICATION PASS; ISSUE-CLOSURE BLOCK

    I independently reviewed the newest retained private evidence set without making an AWS call, repository change, workflow action, or resource mutation. Raw identifiers and the private location remain undisclosed.

    Evidence integrity and query coverage

    • Private containment is correct: the evidence directory is mode 0700 and every contained file is mode 0600.
    • All 22/22 manifested artifacts independently match their recorded byte size and SHA-256 digest. The manifest covers every raw stdout/stderr response plus the four parsed Sponsor artifacts; its five unmanifested directory files are the manifest/index, CLI-version, and investigation-start metadata rather than additional AWS responses.
    • The creation query records exactly 2026-07-12T21:15:00Z–2026-07-12T21:35:00Z, eu-west-1, and EventSource=dynamodb.amazonaws.com.
    • The eight history queries record exactly 2026-07-12T21:15:00Z–2026-07-31T06:11:00Z for CreateTable, TagResource, UntagResource, DeleteTable, RestoreTableFromBackup, RestoreTableToPointInTime, CreateBackup, and UpdateTable.
    • Independent parsing confirms every outer lookup attribute, embedded event name/source, and embedded event timestamp is within the declared query contract. The creation result contains 203/203 DynamoDB events. History contains 125/125 DynamoDB CreateTable events; TagResource contains 3 total events of which 2 are DynamoDB and the non-DynamoDB event is locally rejected; every other history query returns zero events.
    • Both nontrivial responses exceed the configured 50-event page size and are aggregated without a returned NextToken; every other response also has no token. This supports complete AWS CLI automatic pagination rather than a one-page assumption.
    • The retained CLI is AWS CLI v1. That version has no v2 client-side output pager, so omitting its unsupported --no-cli-pager option is semantically equivalent for stdout capture. It does not imply --no-paginate; service pagination remained enabled.
    • All nine raw stderr artifacts are empty (0 bytes, SHA-256 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855). Raw stdout integrity metadata is:
    Query Bytes SHA-256
    creation source 442330 6574da797b9a3ea8ab36341024103e6e426192d855923316e2632c22b084ff86
    CreateTable history 372629 59fe476f2ba7a6d04335493ef805ba4bc770078099da114bc9a6e76698cb1574
    TagResource history 6917 f4c1a21f10433139ab8a34e1f16ea54a4a6d026d6ea334c43122dee7edc11eb9
    each of the six zero-event histories 21 each 450e0ee55f895199f4b307725acfc2edd9d1a11aa63b457c0ed5aa221be0476f each

    Sponsor selection and binding decision

    Independent selection finds exactly one DynamoDB CreateTable event for the Sponsor target in each of the two overlapping queries, and the selected embedded event is identical between them. It is successful, in-region, and within the creation window. No Sponsor TagResource, UntagResource, delete, restore, recreate, backup, or update history is present in the bounded inventory.

    The event explicitly supplies a historical DynamoDB TableId. It does not supply request tags, any stack/logical/tag key, an aws:cloudformation:stack-id value, a CloudFormation stack ARN/path, or another exact StackId binding. CloudFormation service-agent context, timing, name, ARN, and schema are corroboration only. They do not cryptographically link the historical TableId to the exact StackId already found in GitHub provenance.

    Therefore insufficient is the correct four-state classification. This evidence is not conflicting, but it cannot support route A. Combining it with the already-reviewed GitHub deployment evidence only leaves the two immutable identifiers split across unlinked records, which #141 and #140 explicitly define as insufficient.

    Procedural blockers to closing #141

    The evidence verdict is usable, but the issue itself cannot yet receive an unconditional Architecture PASS:

    1. A read-only STS caller-identity check occurred before collection. The CloudTrail evidence collection itself used only cloudtrail:LookupEvents, and no mutation API occurred, but the complete session operation inventory is not literally the issue's single-API inventory. PM must record/accept this deviation or require a compliant recollection; it must not be hidden.
    2. The collection used a separate phone sandbox role, but its least-privilege policy and authoritative session duration/expiry are not independently proved in the retained manifest.
    3. The private manifest lacks an explicit retrieval timestamp and explicit retrieval principal/session provenance record. Filesystem timestamps are not an adequate substitute for the specified provenance field.
    4. Immediate session expiry/revocation and subsequent rejection/authoritative expiry remain a [HUMAN] gate.

    Verdict: ARCHITECTURE PASS on artifact integrity, pagination, Sponsor selection, and insufficient; ARCHITECTURE BLOCK on closing #141 until the session/provenance deviations and HUMAN closure are resolved. No migration, deploy, exception, ownership mutation, or #136 unblock is authorized.

  4. alexeygrigorev commented on Jul 31, 2026

    @alexeygrigorev
    MemberAuthor

    SECURITY BLOCK — evidence is usable only for a fail-closed insufficient verdict

    I independently reviewed the newest private evidence bundle without making any AWS call and without copying private identifiers or storage details.

    Evidence checks that pass

    • Private directory mode is 0700; all 27 contained files are 0600.
    • Every one of the 22 artifacts listed by the private manifest exists, and every listed byte size and SHA-256 matches the retained bytes. The JSON and TSV artifact indexes agree.
    • The manifest records eu-west-1, the exact fixed creation and history windows, the creation-source lookup, all eight required history event names, and automatic-pagination completion.
    • All nine JSON responses parse. Every embedded CloudTrail event parses, agrees with its outer event name/source/id, is in eu-west-1, and falls inside its declared fixed window. No final response contains an unconsumed continuation token.
    • Automatic pagination is substantively demonstrated: the creation-source result contains 203 events and the CreateTable history contains 125 events, both above a CloudTrail page of 50. AWS CLI v1 has no CLI pager, so omitting the unsupported --no-cli-pager client flag while leaving AWS_PAGER empty is functionally safe and does not weaken pagination.
    • Sanitized counts are: creation source 203/203 total/DynamoDB; CreateTable 125/125; TagResource 3/2; and zero events for each of CreateBackup, DeleteTable, RestoreTableFromBackup, RestoreTableToPointInTime, UntagResource, and UpdateTable.
    • Sponsor selection is deterministic and reproduced from both creation and history results: exactly one matching DynamoDB CreateTable event, the two derived selections are byte-identical, the historical TableId is present, and there are no matching Sponsor tag/delete/restore/recreate events in the queried interval.
    • The selected raw event contains no error, is a management event invoked through CloudFormation, and contains the historical TableId. However, the create request contains none of the three CloudFormation ownership tags and supplies no exact StackId. The derived exact-pair count is therefore zero.
    • The four-state classification is correctly insufficient: this is not an exact binding, conflict, or unavailable result. A historical TableId plus CloudFormation invocation/time/name/ARN correlation cannot identify one exact stack incarnation.

    Acceptance controls that remain open or fail

    1. The dedicated identity's only-LookupEvents policy, separation from the deploy role, region restriction, and session lifetime of at most one hour are not proven in the retained bundle.
    2. A pre-collection sts:GetCallerIdentity call was used to validate restored access. It was read-only, but it means the public operation inventory cannot truthfully contain only cloudtrail:LookupEvents, as the issue currently requires.
    3. The bundle retains an investigation-start timestamp and CLI version, but the manifest has no explicit per-query retrieval time, full per-artifact query parameters, or private principal/session provenance.
    4. HUMAN revocation/authoritative expiry and subsequent rejection (or confirmed passage of expiry) are not retained.
    5. The sanitized per-artifact public hash/size record and PM acceptance are not yet posted.

    Do not rerun the bounded queries merely to make this issue appear compliant: the fixed evidence already proves that route A lacks the required exact pair, and another collection would not add the missing StackId to the historical event. Record the sts:GetCallerIdentity deviation honestly, add any authentic pre-existing session-policy/issuance/expiry and retrieval metadata that actually exists (never reconstruct or fabricate it), publish the allowed sanitized artifact integrity inventory, and have the HUMAN/PM decide the remaining access-session checks.

    This issue does not authorize #136. Its substantive evidence may be used by #140 only to fail closed and select route B.

  5. alexeygrigorev commented on Jul 31, 2026

    @alexeygrigorev
    MemberAuthor

    PM reconciliation checkpoint: the complete sanitized counts/digests and insufficient classification are now in the issue body, together with the honest precollection STS identity-read deviation. The evidence is usable and has been consumed by #140; no recollection is authorized. This issue remains open only for authentic session policy/issuance/retrieval provenance if it exists, HUMAN expiry/revocation or authoritative-expiry evidence, and PM disposition of unavailable metadata. Never reconstruct or fabricate missing provenance.

  6. alexeygrigorev commented on Jul 31, 2026

    @alexeygrigorev
    MemberAuthor

    PM tracker reconciliation: removed the duplicate “Remaining closure work” checklist and retained the canonical acceptance checklist. No blocker was weakened: authentic capability/region/duration/isolation evidence or explicit unmet classification, authentic retrieval/session provenance or accepted absence, HUMAN expiry/revocation evidence, and PM disposition of the precollection sts:GetCallerIdentity deviation all remain open. No recollection, inference, reconstruction, or fabrication is authorized.

  7. alexeygrigorev commented on Jul 31, 2026

    @alexeygrigorev
    MemberAuthor

    PM routing correction — nonblocking status made explicit

    Updated the current body to state that #141 blocks neither #140 nor #143 and that #143 independently blocks #136. The substantive insufficient classification, HUMAN session/provenance cleanup, and no-recollection boundary are unchanged. No evidence was accessed or recollected and no unchecked HUMAN criterion was changed.

  8. changed the title [-]Provide one short-lived CloudTrail Event History audit session[/-] [+]Close out the retained CloudTrail audit session record[/+] on Aug 13, 2026
  9. alexeygrigorev commented on Aug 13, 2026

    @alexeygrigorev
    MemberAuthor

    PM CloudTrail-session lifecycle reconciliation — 2026-08-13

    Verdict: KEEP OPEN / BLOCKED on one HUMAN session-closeout record.

    The substantive research no longer needs work:

    I made these PM dispositions now:

    1. Accept the disclosed precollection sts:GetCallerIdentity call as a bounded read-only process deviation. The honest inventory remains LookupEvents plus that identity read, with zero mutation. It must never be rewritten as LookupEvents-only.
    2. Classify the missing exact session policy/issuance/retrieval provenance as permanently unmet metadata. Do not recollect, reconstruct, infer from filesystem time, or substitute current GitHub OIDC sessions.
    3. Preserve authoritative expiry/revocation as the one unwaived HUMAN security closeout.

    Current successful CI OIDC exchanges are separate sessions and cannot prove the earlier phone audit session's expiry. Elapsed time alone is not accepted without an authentic record binding that exact private session.

    Exact next action: the original HUMAN session owner uses only an already-existing issuance/broker/revocation record, retains it privately, and posts the bounded sanitized expiry/revocation confirmation. No AWS/STS/CloudTrail call, credential reuse, or policy change is required or authorized. PM may then close #141. If no authentic record exists, the issue stays blocked unless a separately groomed PM/Security decision explicitly accepts an attestation-only alternative.

    This was issue-only reconciliation. I made no AWS/CloudTrail/STS call, inspected no credential/private artifact, edited no repository file, ran no test, and performed no data/import/export/restore/deployment action.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1ImportantdataData model, migration, storagehumanCode done or issue blocked on human verificationinfraDeployment and infrastructureresearchInvestigation before implementation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions