Skip to main content

Synopsis

Report a snapshot of the content of an AWS S3 bucket to Kosli. To authenticate to AWS, you can either:
  1. provide the AWS static credentials via flags or by exporting the equivalent KOSLI env vars (e.g. KOSLI_AWS_KEY_ID)
  2. export the AWS env vars (e.g. AWS_ACCESS_KEY_ID).
  3. Use a shared config/credentials file under the $HOME/.aws
Option 1 takes highest precedence, while option 3 is the lowest. More details can be found here: https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/#specifying-credentials You can report the entire bucket content, or filter some of the content using --include / --exclude (literal prefix match) or --include-regex / --exclude-regex (Go regular expressions matched against the full object key). In all cases, the content is reported as one artifact. If you wish to report separate files/dirs within the same bucket as separate artifacts, you need to run the command twice. Object keys are never used as local file names: by default each object is downloaded to a temporary file, hashed and removed, and the fingerprint is computed from the keys and the content digests, so any key S3 accepts can be fingerprinted on any operating system. Keys that cannot form a directory tree are rejected and fail the snapshot, naming every key involved: a key containing a .. segment, two keys that resolve to the same path (such as a//b and a/b), or an object whose key is also a prefix of other objects (such as a beside a/b). A legitimate key of that shape can be left out with --exclude-regex (anchor and escape it, since the pattern is a regular expression matched against the whole key); when --include or --include-regex is set, exclude filters are ignored, so narrow the include filter instead. By default each object’s SHA256 comes from downloading the object and hashing it. --fingerprint-source metadata reads the SHA256 checksum S3 stores for the object instead, which skips the download, the temporary disk and the hashing. Everything else, like the keys, the .kosli_ignore rules, the way digests combine into the fingerprint, is the same in both modes, so the fingerprint is identical and a snapshot matches the artifact you attested either way. Two conditions apply:
  • Every contributing object must carry a full-object SHA256 checksum. S3 only stores one when the upload asked for it, for example aws s3api put-object --checksum-algorithm SHA256. Objects without one fail the snapshot, all named in one run.
  • A multipart upload gets a composite SHA256, which hashes the checksums of the parts rather than the object content, so it cannot serve as the object’s fingerprint. Such an object can be collapsed into a single part in place with aws s3api copy-object --checksum-algorithm SHA256 --copy-source yourBucket/yourKey --bucket yourBucket --key yourKey. A root .kosli_ignore is still downloaded in this mode, because its rules decide which objects contribute; the objects it excludes are never fetched and need no checksum. Reading a checksum does not need fewer permissions than downloading: AWS requires s3:GetObject for both, and an SSE-KMS encrypted object additionally needs kms:GenerateDataKey and kms:Decrypt either way.
To specify paths in a directory artifact that should always be excluded from the SHA256 calculation, you can add a .kosli_ignore file to the root of the artifact. Each line should specify a relative path or path glob to be ignored. You can include comments in this file, using #. The .kosli_ignore file is always treated as part of the artifact: its own entries cannot exclude it, so the exclusion list cannot be changed without changing the fingerprint. Paths the list already matches stay excluded whatever is later added there, so keep its entries as narrow as possible.

Flags

Flags inherited from parent commands

Examples Use Cases

These examples all assume that the flags --api-token, --org, --host, (and --flow, --trail when required), are set/provided.
Last modified on October 9, 2026