DataTalksClub / DataTalksClub/dataops

Close out the retained CloudTrail audit session record

Open
#141 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

data human infra P1 research
Dominant language
TypeScript
Stars
2
Forks
0
PR merge metrics
No merged PRs in 30d

Description

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:

  • reuse #141's CloudTrail bundle as Tasks-table provenance;
  • treat #141 as a dependency or preflight;
  • open the private #141 evidence;
  • call CloudTrail to supplement it;
  • infer any #166 identity from the Sponsor event;
  • delay or advance a phase because #141 is open or closed.

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

  • The fixed creation-source and eight history queries used the recorded exact eu-west-1 bounds and filters.
  • Local parsing, full automatic pagination, raw artifact integrity, restrictive private permissions, sanitized counts/sizes/digests, and zero mutation are recorded.
  • The operation inventory honestly records LookupEvents plus the precollection read-only GetCallerIdentity deviation.
  • Architecture and Security accepted artifact integrity and classified the ownership result insufficient; route A remained rejected.
  • #140 consumed the substantive result and closed; #143 completed the supported ownership reset and closed.
  • PM accepts the disclosed GetCallerIdentity deviation for process closure and permanently classifies unavailable policy/issuance/retrieval provenance as unmet rather than fabricated.
  • #141 blocks no issue and is explicitly unrelated to #166 identity, evidence, or rollout gates.
  • [HUMAN] An authentic pre-existing record binds the exact original audit session and proves authoritative expiry passage or revocation in sanitized form, without an AWS call or credential reuse.
  • PM reviews that HUMAN record, records final acceptance, and closes #141. If the authentic record is unavailable, PM does not check this criterion without a separately reviewed Security disposition.

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

  • Any AWS, CloudTrail, STS, IAM, Config, DynamoDB, CloudFormation, backup, PITR, S3, KMS, Support, provider, data, import/export/restore, deployment, or workflow call/action.
  • Credential reuse/testing, session recreation, policy/trust/role change, current OIDC inspection as substitute provenance, or private artifact publication.
  • Recollecting or expanding Event History, creating CloudTrail Lake/trails, reconstructing metadata, or inferring identifiers/expiry.
  • Reopening #140/#143, changing the now-owned Sponsor table, authorizing #136, or contributing evidence/authority to #166.
  • Repository edits/tests, source changes, migration/reset machinery, or production/private data access.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No repository files or tests are in scope. Start by reviewing the exact HUMAN scope and the remaining unchecked acceptance criteria; done means an authentic pre-existing record proves expiry or revocation without AWS access or credential reuse, then PM records acceptance and closes #141.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws
Domain
cloud, infrastructure, security
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.