This key must appear as the first item in all chalk marks, and the value cannot be changed. It is used to identify the beginning of a chalk mark. While JSON objects typically do not support ordered keys, we still require conforming marks to put this one first.

The chalk mark itself may be embedded in various ways, depending on the artifact type. Still, this key is used to help ease detection.

This key should generally never be reported, as it is redundant to do so.

This represents the Chalk version used at the time of the insertion of the Chalk mark. This must be added to each Chalk mark, to help ensure compatibility with future versions.

This gives a readable date that the chalk operation occurred, in the local time zone set for the machine where the marking happened.

This field does not include the time of the marking. For that, you can add the TIME_CHALKED key, use the DATETIME_WHEN_CHALKED key, or use the TIMESTAMP_WHEN_CHALKED key.

This is a string indicating the time of the chalk operation, in human readable format, given in the local time zone of the machine on which the chalk operation occurred. This only has one value per run-- when chalking, TIMESTAMP_WHEN_CHALKED gives per-chalk time values, if desired.

The time zone offset from UTC of the machine on which the chalk operation occurred, as collected when the chalk operation occurred.

This field is a human readable time stamp indicating the time that the chalk mark was made, using the local clock of the machine that did the chalking. The value is a full ISO-8601 Date-time string, including a timezone offset.

For insertion operations (including docker insertion), the value of this field will represent the same moment in time that the reported value of _TIMESTAMP would give for the operation.

This key is reserved for future use; it is not currently used in any capacity.

This returns information about the host on which the chalk operation occurred, collected at the time of that operation. On posix systems, it's taken from the 'version' field obtained from a call to the uname() system call.

This returns the IPv4 address on the local machine used to route external traffic. It's determined by setting up a UDP connection to Cloudflare's public DNS service, but does not involve sending any data.

The node name at the time of the software's chalk mark insertion. On posix systems, this will be equivalent to the uname() field nodename.

The CHALK_ID of the chalk binary used to create the chalk mark

The public key stored within the injecting Chalk binary, as generated by chalk setup. This key is configured to go into a Chalk mark whenever you intend to sign software. It can be added even if you're not signing, however.

The software version for the chalk binary used in creating the chalk mark (see also, INJECTOR_CHALK_ID).

A string consisting of the OS and system architecture of the platform on which the chalk mark was created.

The commit hash used to build the chalk binary that created the chalk mark.

This field contains the full contents of the command line arguments used to invoke chalk at the time of an insertion operation.

Environment variables set at the time when chalk was invoked for an insertion operation.

Data from environment variables defaults to being redacted, meaning the variable names will be reported, but not the contents. However, this can be tweaked on a per-environment variable basis.

The behavior is configured with the following configuration attributes:

• env_always_show, a list of environment variables to show unredacted.
• env_never_show, a list of environment variables NOT to show in this report.
• env_redact, a list of environment variables to redact.
• env_default_action, a value ("show", "redact", "ignore") that indicates what to do for unnamed environment variables. This defaults to "redact".

Currently, this filtering is not handled per-report, meaning ENV and _ENV will always be identical if you attempt to collect both at chalk time.

A user-defined unique identifier, intended to represent a unique user in multi-tenant environments. This key is set only at the time in which a chalk operation occurs. Its value can be used at that time for various URL substitutions (for instance, in the CHALK_PTR key).

The default OSS configuration never sets this value, but it can be configured manually, or in binaries created by tooling.

This is a unique identifier for an unchalked software artifact. When possible, if the same unchalked artifact is chalked on two different machines, it will give identical CHALK_IDs.

Chalk marks are always four groups of characters separated by dashes; the first and last group are six characters, and the middle two groups four characters.

The non-dash characters are taken from a base32 character set, and the letters will always be upper case.

Any time a chalk mark is created for a piece of software, this field must be part of the mark.

Whenever possible, the CHALK_ID will be derived from the hash of the unchalked artifact (we encoded 100 bits from the hash). This helps ensure that different machines will calculate the same CHALK_ID on the same artifact.

Currently, the hash is used for calculating this value for all artifact types EXPECT docker images, where we cannot reliably get such a value. In that case, the value is randomly selected, and will be different every time.

This identifier differs from the METADATA_ID in that the CHALK_ID is a unique identifier for the unchalked artifact, whereas METADATA_ID is a unique identifier for the CHALKED artifact. A single file can have multiple METADATA_IDs when chalked multiple times, but only one CHALK_ID (again, excepting docker images).

See the documentation for METADATA_ID for more information.

This field consists of the number of milliseconds since the Unix epoch, at the time the chalk mark was created for the given artifact. The Unix epoch started at the beginning of Jan 1, 1970, UTC.

When multiple pieces of software are marked in the same run of Chalk, this will generally indicate the time between chalks.

If, instead of an integer, you would like a more readable representation, check out the DATE_CHALKED, TIME_CHALKED, TZ_OFFSET_WHEN_CHALKED and DATETIME_WHEN_CHALKED keys, though those keys are computed once per-run, and not on a per-artifact basis.

This field is set at Chalk time, and is user definable. It should be used to inject a URL into the software, where the URL indicates the location of the report created at Chalk time for this artifact.

There are special substitution variables to allow you to include artifact-specific information in the URL, all of which are evaluated at the time of chalking:

• {chalk_id} is replaced with the CHALK_ID for this software.
• {now} is replaced with an integer timestamp, and will be identical to the value of the software's TIMESTAMP_WHEN_CHALKED field, if used.
• {path} is replaced with the PATH_WHEN_CHALKED field for the artifact, generally representing the software's location on the file system at the time of chalking.
• {hash} is replaced with the software artifact's HASH field (the Chalk hash; see chalk help hashing).
• {tenant} is replaced with the software artifact's TENANT_ID_WHEN_CHALKED field, as set at the time of chalking.
• {random} is replaced with the value of CHALK_RAND, as set at the time of chalking.

The above substitutions all occur, even if the given keys are not added to the software's chalk mark. See the documentation on those individual metadata keys for more information about their semantics.

This key represents the file system path for the artifact, at the time the chalk mark was added.

For items chalked when they were in a ZIP file, this field gets their path within that ZIP file.

For items chalked when they were in a embedded into a ZIP file, this is the CHALK_ID of the containing artifact.

A string indicating the type of a software artifact, as determined when the chalk mark was added. Values can include:

• ELF (non-MacOS Unix)
• Mach-O executable
• Unix Script
• Docker Image
• Docker Container
• Python
• Python Bytecode
• ZIP
• JAR
• WAR
• EAR

Hash file of artifact w/o chalk in it, to ensure extracted chalk is intact. The hash algorithm is specific to the codec, and is generally a normalization of the file that is format specific.

It is NOT the file system hash. For Chalk's purposes, even when inserting a chalk mark, the file system hash is not a good hash to use to decided whether two artifacts are the same non-chalked item. For instance, if you chalk an artifact that has already been chalked, the chalk HASH algorithm will see they're the same artifact, but the file system hashes would definitely differ.

Also, for some codecs, due to file format complexities, if you DELETE a chalk mark from an artifact, you may not get the same bits back as before any chalk mark was inserted.

That's because there's a normalization process applied, and reversing it is not worth the effort, especially for things like ZIP files and ELF binaries, where the logic involved would be complex, and it would also require storing data.

The codec-specific normalization process ensures the artifact semantics are always valid, and that we have a consistent way to hash. It just doesn't always enable recovering the original bits.

Nonetheless:

1. The _CURRENT_HASH key will always give you the hash of the file on the file system, at the end of the current operation.

2. For file system artifacts, The PRE_CHALK_HASH field will give the file system hash before insertion. However, this is calculated without considering whether it is already chalked of not.

Additionally, some types of artifact (particularly Docker containers) may not have a pre-chalk HASH value that we can easily compute, in which case this field will not be reported.

See chalk help hashing for more information.

For chalking operations only, this is the SHA-256 hash value of the file, before the chalking operation took place.

This key does process chalk marks, only bits on disk. That is, if the file was previously chalked before the current insertion, the hash will include the old chalk mark being replaced.

The run-time key _CURRENT_HASH is available on all operations, and for file system objects, gives the hash on disk after the operation concludes.

The URI associated with the origin of the source code repository found at the time of chalk mark insertion.

The branch name found in the source code repository found at the time of chalk mark insertion.

The most recent commit hash or id for the current repository and branch identified at the time of chalk mark insertion.

This is reserved for future use; plugins specific to managed software environments are expected to set this field. However, you can manually set this value if desired.

This metadata key is meant to represent a software artifact's version information, at the time that a chalk mark is inserted.

This field's value should be set to the URI of the software artifact's intended storage location, at the time of chalking. Generally, this field is meant for internal repository information, not public information.

Currently, this field is not set by any chalk plugins. The user can configure it to be set to a custom value.

This field can apply any of the same substitutions supported in the CHALK_PTR field (see that key for details).

This field's value should be set to the URI associated with a primary public distribution point for the software artifact, as of the time of chalking.

Currently, this field is not set by any chalk plugins. The user can configure it to be set to a custom value.

This field can apply any of the same substitutions supported in the CHALK_PTR field (see that key for details).

This contains any identified code owners at the time that software was chalked. Generally, this is a free-form field.

In the case where the chalking operation finds a CODEOWNERS or AUTHORS file, it currently captures the entire free-form file. The system does NOT currently attempt to extract only relevant parties, based on local file system path.

The version control directory tied to an artifact, identified at the time of chalking.

This will contain the path information as found on the host on which the artifact was chalked.

If, at the time of chalking, the system can field will contain the associated job ID.

If, at the time of chalking, the system can identify a CI/CD job, this field will contain the URI associated with the job, if found.

This field is generally expected to be supplied by the user, and can use the same substitutions allowed for the CHALK_PTR field (see that key's documentation for more detail).

If, at the time of chalking, the system an identify a CI/CD job, and there is a discernible API endpoint, this field will contain the URI for that endpoint.

This field is generally expected to be supplied by the user, and can use the same substitutions allowed for the CHALK_PTR field (see that key's documentation for more detail).

Any recorded build trigger found at chalk time.

Contact information set at chalk time for the person or people associated with the triggered CI/CD job.

A 64-bit random value created at chalk time only. This field is selected per chalk (if enabled), and is intended to help ensure unique METADATA_ID fields for artifacts in all circumstances. This is encoded as hex digits.

This is intended for those people who want to be able to trace specific artifacts to a specific build system.

Certainly, this key should be disabled in chalk marks if attempting reproducible builds (in which case, also be sure not to chalk any keys consisting of timestamps).

While there is a config-file callback associated with this metadata key, it is set by the system, and cannot be overridden by the user.

In cases where a chalk insertion operation is being performed on a software artifact that already contains a chalk mark, this field represents the value of the METADATA_HASH field of the chalk mark that is being replaced.

This helps support traceability in multi-stage CI/CD processes, where it makes sense to inject (and/or report on) data at different points.

This field assumes that the old chalk mark was previously reported on, in which case this field can be used as a reference to recover the linked information.

See also the related key OLD_CHALK_METADATA_ID, which essentially serves the same purpose, but using a different representation of the data.

In cases where a chalk insertion operation is being performed on a software artifact that already contains a chalk mark, this field represents the value of the METADATA_ID field of the chalk mark that is being replaced.

This helps support traceability in multi-stage CI/CD processes, where it makes sense to inject (and/or report on) data at different points.

This field assumes that the old chalk mark was previously reported on, in which case this field can be used as a reference to recover the linked information.

See also the related key OLD_CHALK_METADATA_HASH, which essentially serves the same purpose, but using a different representation of the data.

In cases where a software artifact consists of a container consisting of other software artifacts, this field captures the full chalk marks for any such embedded software, at the time in which artifacts are chalked.

The format of this key is an array of chalk marks, identical to the contents of the _CHALKS key.

Currently, this embedding can only be recorded with ZIP-formatted artifacts, such as JAR files. This will not be collected unless the configuration variable chalk_contained_items is set.

We do not currently support this capability with containers, or any other type of embedded artifact.

When chalking embedded contents, the system uses a temporary directory. This key captures the directory used for that operation. Any directories in the sub-chalk will be under this path, which will be reflected in path information for embedded artifacts.

Deprecated, and only available for the simplest of AWS environments.

Instead, please use individual metadata fields for cloud provider metadata.

This field is meant to captures any SBOMs associated with a chalking (i.e., a chalk mark insertion operation). The value, when provided, is a dictionary. The keys of that dictionary indicate the tool used to perform the chalking, and the value consists of a free-form JSON object returned if the SBOM creation is successful.

Currently, the only supported tool integration is syft. It does not run by default, but if you enable the config variable run_sbom_tools (which can be also done on the command line with --run-sbom-tools), and if you configure the key to be chalked or reported (by editing the appropriate profile), then chalk insertion operations will attempt to run the tool, even downloading it from its official distribution source if needed.

You may also set the field yourself if you have other tooling for collecting this information.

This field captures any static analysis security tooling reports that are associated with a chalking (i.e., a chalk mark insertion operation). The value, when provided, is a dictionary. The keys to that dictionary indicate the tool used to perform the chalking, and the value consists of a free-form JSON object returned if the SBOM creation is successful.

Currently, the only supported tool integration is semgrep. It does not run by default, but if you enable the config variable run_sast_tools (which can be also done on the command line with --run-sast-tools), and if you configure the key to be chalked or reported (by editing the appropriate profile), then chalk insertion operations will attempt to run the tool, even downloading it, if needed, from its official distribution source (via Python's pip, which you will need locally for this to work).

You may also set the field yourself if you have other tooling for collecting this information.

This can capture any errors or other logging information reported during the chalk insertion process. The errors are filtered based on log level.

Only messages of a log level at least as severe as that found in the configuration variable chalk_log_level are capture. By default, this value is set to "error".

That configuration variable is independent from the log_level variable that controls console logging output.

This key must be added into chalk marks whenever chalk marks are being digitally signed, to help ensure that it's possible to detect deleted signatures.

It also generally does NOT need to be reported. If this field isn't reported, and an attacker attempts to delete a signature, they could remove this field. However, the (required when signing) METADATA_HASH field will NOT validate if this field is deleted.

This field is used to help authenticate the rest of the metadata placed into the chalk mark. It constitutes a hash of all the metadata that is in the actual chalk mark.

Again, this is NOT derived from the insertion-time report; instead, it is derived from the remainder chalk mark itself. That way, whenever the chalk mark is extracted, the contents can be validated, thus detecting whether software has been changed since marked.

For instance, if you mark a shell script, and then edit it, you will get a validation error on any subsequent operation involving that artifact until a new mark is inserted, the changes are reverted, or the mark is deleted.

We use a simple binary normalization format for the hash, which sorts keys in a well-known order. METADATA_ID isn't used in this computation since it is derived from the METADATA_HASH, and signature-related fields are not used, since they sign this value.

Whenever available at chalk time, the HASH field should be added to artifacts (or the CHALK_ID, which would be derived from the same value), in which case the METADATA_HASH protects the integrity of the entire artifact, not just the associated metadata.

The METADATA_ID field is derived from the METADATA_HASH value, but is more human-readable. It can also be used for metadata integrity, which is why this field is not strictly required in a chalk mark.

This is a more readable unique identifier for a chalked artifact. It is always derived from 100 bits of the artifact's METADATA_HASH field, and is encoded in the same way the CHALK_ID key is.

Embedded digital signature for artifact. Note that this is only supported for file system artifacts; containers and images use detached signatures only.

Signatures are generated using the In-Toto standard.

When chalking docker containers, this gets the contents of the topmost docker file passed to the docker command line, prior to any chalking.

Platform passed when performing docker build, if any.

Platform passed when performing 'docker build', if any.

Labels added to a docker image during the build process, if any.

Tags added to a docker image. Will be in the form: REPOSITORY:TAG

The docker context used when building a container.

Additional contexts specified when building a container.

List of labels programmatically added by Chalk.

Additional instructions added to the passed dockerfile.

If there was no tag when the build command is run, we use a temporary tag so we can reliably inspect it after the build.

A string indicating the type of a software artifact, as determined at the time a report was generated. The possible values are identical to those listed in the documentation for the chalk-time key, ARTIFACT_TYPE.

During insertion operations, this key is redundant with ARTIFACT_TYPE, so there is generally no reason to report on both of these at insertion time.

The file system location (or alternate location information if not file-system based) for a given artifact, in the environment local for the current operation. For instance, if running a chalk extract operation or a chalk exec operation, this value will represent where software is at the time, which likely will not match the path captured during the build process (which lives in the PATH_WHEN_CHALKED key).

However, on insertion operations, this field is redundant with PATH_WHEN_CHALKED, except that it cannot be added to a chalk mark.

This field contains the SHA-256 hash of a software artifact, as calculated by its codec, at the end of the current chalk operation, whatever it is.

On insertion operations, this will capture the post-chalking hash value, and thus will generally be different than the value of the HASH key.

For extraction and exec operations, since they do not modify the artifact, this will represent the same post-chalked artifact hash, except in cases where the artifact isn't chalked, naturally.

This is set to true if an object's metadata is okay, and the chalk mark was well-formed. If an object is unsigned, this being true does NOT mean that the metadata is authentic, just that the data is all consistent. If there is also a validated signature as well, _VALIDATED_SIGNATURE will also be true.

This is set to true if a signature is both present and validated in an artifact.

If, for some reason, there is a signature but we could not validate (e.g., the public key is not available), then this will be set to false.

However, this doesn't indicate tampering; in the case of a failed validation, this key is omitted, and _INVALID_SIGNATURE will be true.

This reporting field indicates that a chalk mark was created for a given artifact, but that the mark was NOT inserted into the artifact (ideally, it would have instead been escrowed somewhere easy to track).

Despite the fact that this key cannot be inserted into a chalk mark, it is only ever set when performing chalking operations.

Collected for chalk insert operations only, a list of all keys that were added to the chalk mark. This only consists of the names of the keys chalked, not any of the values.

Collected for chalk insert operations only, a list of all artifact specific key names that will reported on in the primary operation report. This is primarily intended for auxiliary (custom) reports where the full contents are not being duplicated.

The process ID of the running process associated with the artifact.

Currently, this is only available during a 'chalk exec' operation, where Chalk has been configured to report when spawning the container entry point.

Collects key process info; the same info as in _OP_ALL_PS_INFO, but only for the given process.

This overlaps with many of the other keys beginning with _PROCESS.

If you use this key, then the only such keys that do not overlap are: _PROCESS_FD_INFO _PROCESS_MOUNT_INFO Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

The process ID of the parent process.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

Process start time, in seconds since boot.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

The amount of time the process has spent in user mode since starting, in seconds.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

The amount of time the process has spent in kernel mode since starting, in seconds.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

User mode time of the proc's waited-for children.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

Kernel mode time of the proc's waited-for children.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

The state of the process (e.g, Running, Sleeping, Zombie, ...)

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

The process group associated with the process.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

The umask associated with the process.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

A list containing the real, effective, saved and fs UID of the process.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

A list containing the real, effective, saved and fs GID of the process.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

The number of allocated file descriptors.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

A list of the supplementary groups to which the process belongs.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

The process' Seccomp status (disabled, strict or filter).

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

The argv as reported via proc for the exec'd process we are reporting on.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

The current working directory of the process.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

The path to the executable of the process being reported on.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

The current name of the process image being reported on.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

Returns information for all file descriptors in the process. Keys are file descriptor numbers, but encoded as a string.

Values are dictionaries of info that vary based on the file type.

A list of mounts available to the process.

Currently, this is only available during a chalk exec operation, where Chalk has been configured to report when spawning the container entry point.

All reported metadata for am image as examined, in JSON format. With docker, this is equivalent to running docker inspect on the image.

All reported metadata for the running container, as reported by the container runtime, in JSON format. With docker, this is equivalent to running docker inspect on a running container.

The image ID reported by docker for a container image.

Any comment explicitly set for the image.

The DATETIME formatted string for the reported container image creation time.

Docker version used to built the image

The author of the image (see LABEL maintainer)

The reported architecture that the image was built for, for example amd64 or ppc64le.

Specifies a variant of the CPU, for example armv6l to specify a particular CPU variant of the ARM CPU.

Linux. The answer is linux.

Specifies the operating system version, for example 10.0.10586.

The size in bytes of the image. This field exists so that a client will have an expected size for the content before validating. If the length of the retrieved content does not match the specified length, the content should not be trusted.

The type of the image's root filesystem

The layer IDs of the image's root filesystem

The hostname a container uses for itself.

The domain name of the image.

User associated with the image.

Explicitly configured ports that instances of the image may bind to on external interfaces. The keys will be of the form 'port/family', e.g., 446/tcp. The values are info about specific interfaces where those ports are bound, if provided. Otherwise, it's expected to be across all interfaces.

The environment configuration of an image.

The default CMD of an image with its arguments.

The image name associated with a container, as reported by the runtime.

Healthcheck command to be run to determine health status.

Interval by which to run the healthcheck command.

Timeout after which the healthcheck is considered failed/unhealthy if not OK.

Healthcheck start period provides initialization time for containers that need time to bootstrap. Probe failure during that period will not be counted towards the maximum number of retries.

The time between health checks during the container start period.

How many time to attempt to retry the healthcheck before considering it failed.

Different types of mounts (e.g., cache, bind) of an image

The WORKDIR instruction switches to a specific directory in the Docker image, like the application code directory, to make it easier to reference files in subsequent instructions.

The path to the command within the contained file system, relative to the root of the environment.

Whether the networking stack of a container is isolated or not

The set MAC address for a container

The ONBUILD instruction which adds to the image a trigger instruction to be executed at a later time, when the image is used as the base for another build.

Key-value pairs adding metadata to images

The signal to be sent to the main process inside the container, which by default is SIGTERM

The timeout, which is 10 seconds by default for each container to stop. If even one of your containers does not respond to SIGTERM signals, Docker will wait for 10 seconds at least.

The shell used within an image (e.g., /bin/sh) used to execute ENTRYPOINT, RUN and/or CMD commands

The amount of data used for the read-only image data used by the container plus the container's writable layer size.

Last time an image was tagged.

Storage metadata (key value pairs) associated with an image.

URI where an artifact is none to have been stored, generally as a part of the current operation.

Any reported instance ID, such as the container ID for a running container.

The DATETIME formatted string for the reported container creation time.

The path to the command, if running in a containerized / virtual environment. The path is relative to the root of the environment.

The arguments used when starting the instance.

Environment variables made available to the instance, in VAR=value format.

Configuration path for DNS settings of the instance

Configuration path for hostname settings of the instance

Configuration path for hosts settings of the instance

Path for storing logs for instance execution

The image ID associated with the instance, as a hash. Will generally be lower-case ASCII prefixed with the string sha256:

The status of a container or virtual instance (running, paused, stopped, etc) as reported by the container runtime.

The process ID of the instance as reported by the container runtime. This will generally be the actual PID, not a virtualized PID.

The name this container instance has been given by the container runtime.

The number of restarts the runtime reports associated with the container.

The instance driver (e.g., docker container driver, buildx) used, as reported by the runtime.

Platform of an instance, as reported by the runtime.

Mounts labels associated with the running container.

Process label for a running instance.

Any AppArmor profile enabled for the instance.

Instance execution ids as captured at runtime..

Binds specified for a running instance.

An instance's container ID file

Log configuration for a running instance.

Network mode for a running instance.

Name of the restart policy for the running instance.

An instance's restart retry count.

Whether the container should be getting removed after its stopped

Volume driver information (e.g., vieux/sshfs driver info) related to a running instance

Mount an instance's volume from another container as described in this option

An instance's console size

Capabilities explicitly added to an instance.

Capabilities explicitly dropped from an instance.

Cgroup namespace mode of an instance

DNS settings for an instance

DNS options configured for the instance

DNS search configuration for an instance.

Additional hosts to be looked up when there are network or DNS issues

IPC mode of an instance

CGroup associated with the instance, as reported by the container runtime

Links of a running instance (legacy): The link feature allows containers to discover each other and securely transfer information about one container to another container"

Running instance's OOM preferences (-1000 to 1000)

The PID mode of the container (e.g. "host")

Whether or not the workload is running with admin privileges on the underlying node.

Whether the instance publishes all exposed ports to the host interfaces

Whether the root file system is immutable. Note that this does not preclude filesystem mounts that allow writing.

Security options for the running instance.

UTS namespace mode for the running instance.

User namespace mode for the running instance.

Size of /dev/shm for the running instance. The format is

The container runtime associated with the instance.

Isolation technology in use for the instance, if reported by the container runtime.

A value greater or less than the default of 1024, increases or reduces the instances's weight, and gives it access to a greater or lesser proportion of the host machine's CPU cycles

Memory allocated to the running instance

Instance's NanoCpus that represents CPU quota in units of 10-9 CPUs.

Optional parent cgroup for the running instance

Instance's block IO weight (relative weight). Accepts a weight value between 10 and 1000.

Instance' block IO weight (relative device weight, format: DEVICE_NAME:WEIGHT)

Instance's limit on read rate from a device (format: :[]). Number is a positive integer. Unit can be one of kb, mb, or gb

Instance's limit on write rate to a device (format: :[]). Number is a positive integer. Unit can be one of kb, mb, or gb.on

Instance's limit read rate (IO per second) from a device (format: :). Number is a positive integer.

Instance's limit on write rate (IO per second) to a device (format: :). Number is a positive integer.

Instance's limit on the CPU CFS (Completely Fair Scheduler) period

Instance's limit the CPU CFS (Completely Fair Scheduler) quota

Instance's limit on the CPU real-time period. In microseconds. Requires parent cgroups be set and cannot be higher than parent. Also check rtprio ulimits.

Instance's limit on the CPU real-time runtime. In microseconds. Requires parent cgroups be set and cannot be higher than parent. Also check rtprio ulimits.

Instance's CPUs in which to allow execution (0-3, 0,1)

Instance's memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.

Instance's devices.

Instance's cgroup rules.

Instance's device requests.

The platform must guarantee the container can allocate at least the configured amount of memory

The amount of memory this container is allowed to swap to disk

Setting from 0 to 100 tuning the percentage of anonymous pages used by a running container instance that the host kernel can swap out.

Whether the out of memory kill is disabled for the running instance.

The limit of an instance's PIDs. -1 denotes unlimited PIDs.

ulimit settings for the running instance.

CPU count for the running instance.

Percentage of CPU for the running instance

IO max IOPS setting for the running instance

IO max BPS for the running instance

Paths that are masked for the running instance, as they are not safe to mount inside the running instance.

Paths that are read-only for the running instance.

Storage metadata for the running instance.

Mounts associated with the running container.

The hostname of the instance, if reported by the container runtime.

The domain name of the instance, if any.

The user reported by the runtime, if any.

Wether stdin is attached to a running instance, so it can be used within chained pipe commands.

Wether stdout is attached to a running instance, so it can be used within chained pipe commands.

Wether stderr is attached to a running instance, so it can be used within chained pipe commands.

Information on exposed ports from the runtime. The keys will be of the form 'port/family', e.g., 446/tcp. The values are info about specific interfaces where those ports are bound, if provided. Otherwise, it's expected to be across all interfaces.

Whether the instance is using a TTY.

Instance's stdin open status

Whether the container runtime should close the stdin channel after it has been opened by a single attach.

Instance's CMD

Instance's config image

Instance volumes

WORKDIR of a running instance

Instance's entrypoint directive

Instance on build directive

Reported labels attached to the instance.

Instance bridge setting

Instance sandbox id

HairpinMode of an instance

Instance local IPv6

Instance local IPv6 prefix length

Information on bound ports from the runtime. The keys will be of the form 'port/family', e.g., 446/tcp'. The values are info about specific interfaces where those ports are bound, if provided. Otherwise, it's expected to be across all interfaces.

Instance sandbox key

An instance's secondary IPs

An instance's secondary IPv6 addresses

An instance's endpoint id

The network gateway used by the instance.

The externally bound IPv6 address for a container instance.

An instance's global IPv6 prefix length.

The primary IPv4 address for the instance.

An instance's IP prefix length.

The network gateway used by the instance for IPv6 traffic, if any.

The MAC address associated with the instance's primary network instance.

Networks for a running instance.

When reporting on operations involving a repository (e.g., a push or pull), any tags associated with the artifact in the operation.

When reporting on operations involving a repository (e.g., a push or pull), any SHA256 digests associated with the artifact in the operation, mapped to the associated tag.

When extracting from a docker image that is unmarked at the top layer, if lower layers are searched, this will be set to the found values of CHALK_ID and METADATA_ID, in the highest layer where a mark was found.

These values will not have been validated.

Digital signature for artifact. For build/push operations, this will generally represent the digital signature added as part of the operation. For extraction operations, it represents a validated extracted signature.

Set to true (and is only set) if there was an attestation that explicitly did not validate.

This is a unique identifier generated for the current run of chalk. It is not insertable into chalk marks, but may appear in any host report.

The purpose of this value is to ensure every chalk action has a unique identifier, if desired.

The value is a 64-bit (secure) random value, encoded as hex.

While there is a config-file callback associated with this metadata key, it is set by the system, and cannot be overridden by the user.

The full contents of argv used on invocation

This field, which can only appear in reports, contains information about environment variables at the time of ANY chalk invocation. For a chalkable version, see the documentation for INJECTOR_ENV.

Because chalk may be used to proxy container entry points that could contain sensitive data, we support to redacting environment variables, including skipping them outright. The behavior is configured with the following configuration attributes:

• env_always_show, a list of environment variables to show unredacted.
• env_never_show, a list of environment variables NOT to show in this report.
• env_redact, a list of environment variables to redact.
• env_default_action, a value ("show", "redact", "ignore") that indicates what to do for unnamed environment variables. This defaults to "redact".

Currently, this filtering is not handled per-report, meaning INJECTOR_ENV and _ENV will always be identical if you attempt to collect both at chalk time.

Akin to TENANT_ID_WHEN_CHALKED, but will not be added to a chalk mark, and can be set for any given operation. The default OSS configuration never sets this value, but it can be configured manually, or in binaries created by tooling.

This field can be provided for any chalk report, and represents the top-level command used to invoke chalk. The value might be slightly different from the one invoked on the command line, even though it is often the same.

This field will always be one of the following values:

• insert, created via chalk insert
• extract, created via chalk extract
• build, created via chalk docker commands that build a container.
• push, created via chalk docker commands that push a container (at which point we collect data to link the build image to the pushed image).
• exec, created when chalk exec is used to spawn a process.
• heartbeat, used for subsequent reports when chalk exec is used.
• delete, created via chalk delete
• env, created when chalk env is called to create a moment-in-time report for a current environment.
• load, created when a new configuration is inserted into a chalk binary.
• setup, used for reporting on self-chalking after chalk setup is run.
• docker, created for other (unhandled) docker commands, but not used in the default configuration.

These values correspond to the names used by the outconf configuration section for setting up report I/O.

The help, dump, version, and defaults commands do not ever generate reports.

For the current operation only, this represents the number of milliseconds since the Unix epoch. See the documentation for the TIMESTAMP key for more details.

This is collected and reported on a per-chalk-invocation basis, not on a per-software-artifact basis. It also cannot be directly added to a chalk mark (but can be in a report for any chalk operation).

A human-readable date associated with the operation currently being reported on. This is derived from the same value used if _TIMESTAMP is reported.

A human-readable string containing the time associated with the operation currently being reported on. This is derived from the same value used if _TIMESTAMP is reported.

This value is reported based on the clock and time zone of the machine performing the chalk operation.

The Time Zone offset from UTC for the current chalk operation.

A full ISO-8601 Date-time w/ timezone offset for the current operation, derived from the same value used to set the _TIMESTAMP key.

Used to report chalks the operation worked on.

IMPORTANT!

Host reports using a profile that does not configure this key to report will NOT output chalks.

The number of chalks the operation worked on, meant primarily for contexts where the chalks themselves are not being reported, such as when reporting on aggregate stats.

The number of unmarked artifacts that codecs saw in the current operation. For inserts, this number will represent the number of items that come codec was willing to chalk, except that the configuration indicated to ignore the file (which will frequently happen with scripts in a .git directory, for instance). For non-insertion operations, the value will represent the number of software artifacts processed that did not contain chalk marks.

Fully resolved command-line flags and values used in the current chalk command's invocation.

This is slightly different from _ARGV in that arguments may have experienced some processing.

The artifact search path used for the current chalk command's attempt to locate chalked artifacts.

The executable name for the current chalk invocation, which is approximately argv[0].

This key attempts to use information from the command-line invocation of chalk, instead of system-specific information on running processes (see _PROCESS_COMMAND_NAME).

The local path to the chalk executable for the current invocation. This generally does not include the actual exe name.

This key attempts to use information from the command-line invocation of chalk, instead of system-specific information on running processes (see _PROCESS_EXE_PATH).

This field contains the full contents of the command line arguments used to invoke chalk for the current invocation. This field cannot be inserted into chalk marks, but will have the same value as the INJECTOR_ARGV key on any insertion operations.

The contents of any user-definable configuration file used in the current operation, if an external configuration file is used at all (otherwise, even if requested, no value will be returned)

A list of artifact path information for any artifacts identified during the current operation that were NOT marked. For insertion, this means artifacts a codec should have processed but didn't due to error. Otherwise, it will indicate a software artifact that the system could have marked, but where no mark was found.

The commit hash of the repository used to build the chalk binary used in the current operation.

Version information for the chalk command used in the current chalk invocation.

Platform info (os and architecture) for the current chalk invocation.

Hostname information found that is associated with the machine on which the current chalk command was executed.

This returns information about the host on which the urrent operation occurred, collected at the time of that operation. On posix systems, it's taken from the 'version' field obtained from a call to the uname() system call.

This returns the IPv4 address on the local machine used to route external traffic. It's determined by setting up a UDP connection to Cloudflare's public DNS service, but does not involve sending any data.

There are other keys for reported IPs via other systems, including cloud provider APIs, docker, procfs, etc.

The node name at the time of the current operation. On posix systems, this should be equivalent to the uname 'nodename' field.

Deprecated, and only available for the simplest of AWS environments.

Instead, please use individual metadata fields for cloud provider metadata.

Errors identified during the current operation, not associated with a particular artifact. See the documentation for ERR_INFO, which shares the same log-level configuration.

Collected for chalk insert operations only, a list of all host-level key names that will reported on in the primary operation report. This is primarily intended for auxiliary (custom) reports where the full contents are not being duplicated.

On Linux machines, will return information about existing TCP sockets, to the degree that the chalk process has permissions to access this information.

One socket is returned per row. The columns returned are:

1. The local IP address in use
2. The local port number in use
3. The remote IP address in use
4. The remote port number in use
5. The status of the connection (e.g., LISTEN, CONNECT, ...)
6. The UID of the process that owns the socket
7. The inode associated with the socket

When running Chalk inside a container, this information will be the virtualized view available insider the container.

On Linux machines, will return UDP state information, to the degree that the chalk process has permissions to access this information.

One socket is returned per row. The columns returned are:

1. The local IP address in use
2. The local port number in use
3. The remote IP address in use
4. The remote port number in use
5. The status of the connection (always UNCONN)
6. The UID of the process that owns the socket
7. The inode associated with the socket

When running Chalk inside a container, this information will be the virtualized view available insider the container.

On Linux machines, will return IPV4 routing table information, to the degree that the chalk process has permissions to access this information.

One route is returned per row. The columns returned are:

1. The destination network
2. The next hop (gateway address)
3. The netmask for the route
4. The interface (device) associated with the route
5. The kernel's 'Flags' field
6. The kernel's 'RefCnt' field
7. The kernel's 'Use' field
8. The kernel's 'Metric' field
9. The kernel's 'MTU' field
10. The kernel's 'Window' field
11. The kernel's 'IRTT' field

When running Chalk inside a container, this information will be the virtualized view available insider the container.

On Linux machines, will return IPV6 routing table information, to the degree that the chalk process has permissions to access this information.

One route is returned per row. The columns returned are:

1. The destination network
2. The destination prefix length in hex
3. The source network
4. The source prefix length in hex
5. The next hop (gateway address)
6. The interface (device) associated with the route
7. The kernel's 'Flags' field
8. The kernel's 'RefCnt' field
9. The kernel's 'Use' field
10. The kernel's 'Metric' field

When running Chalk inside a container, this information will be the virtualized view available insider the container.

On Linux machines, will return information on IPV4 interface status.

One interface is listed per row. The first column is the interface name.

The next 8 columns are receive statistics: bytes, packets, errors, drops, fifo, frame, compressed, multicast

The remaining columns are transmission statistics: bytes, packets, errors, drops, fifo, colls, carrier, compressed

When running Chalk inside a container, this information will be the virtualized view available insider the container.

On Linux machines, will return information on IPV6 interface status.

One interface is listed per row. The first column is the interface name.

The remaining columns are:

• The netlink device number in hex
• The prefix length in hex
• The kernel's 'Scope value' (see include/net/ipv6.h)
• The kernel's 'Interface flags' (see include/linux/rtnetlink.h')

When running Chalk inside a container, this information will be the virtualized view available insider the container.

On Linux machines, will return the ARP table.

One row is returned for each ARP entry. The columns are:

1. The IP address
2. The kernel's recorded hardware type
3. Any flags set in the kernel for the ARP entry
4. The associated hardware address.
5. The kernel's record 'Mask' field
6. The network device from which the entry broadcasts.

When running Chalk inside a container, this information will be the virtualized view available insider the container.

Currently, this just returns CPU basic load average info, including number of processes.

The values are all presented as strings. The current available item info is:

• load: load averages over the last 1, 5 and 15 mins
• lastpid: the last PID handed out by the system
• runnable_procs: the number of current running processes
• total_procs: the total number of running processes.

When running Chalk inside a container, this information will be the virtualized view available insider the container.

For every process visible to Chalk, reports key process info. The keys are the PID as a string, even when they are clearly numeric values.

The values are dictionaries of information associated with that process:

• state: The state of the process (e.g, Running, Sleeping, Zombie, ...)
• ppid: The parent process ID
• pgrp: The process group
• sid: The session ID of the process.
• tty_nr: The encoded TTY number for the controlling terminal of the process.
• tpgid: The ID of the terminal's process group.
• user_time: The amount of time the process has spent in user mode since starting, in seconds.
• system_time: The amount of time the process has spent in kernel mode since starting, in seconds.
• child_utime: User mode time of the proc's waited-for children.
• child_stime: Kernel mode time of the proc's waited-for children.
• priority: The real-time scheduler's priority field reported by Linux.
• nice: The nice value for the process (higher numbers are lower priority)
• num_threads: The number of threads in the process.
• runtime: The time since the process started, in seconds.
• uid: A list containing the real, effective, saved and fs UID
• gid: A list containing the real, effective, saved and fs GID
• fd_size: The number of allocated file descriptors
• groups: A list of the supplementary groups to which the process belongs.
• seccomp: The process' Seccomp status ('disabled', 'strict' or 'filter')
• umask: The umask associated with the process.
• argv: The command line used when exec'ing the process.
• path: The path to the executable.
• cwd: The cwd of the process.
• name: The short name of the process, as determined by /proc/pid/stat
• command: The short name of the command, as determined by proc/pid/comm

When running Chalk inside a container, this information will be the virtualized view available insider the container.

In case of chalk running in the cloud, the type of the cloud provider the node is running in. Currently the only supported values are gcp, aws, azure

In case of chalk running in the cloud, the account ID or other identifying metadata for the account owning the environment in which chalk executes in.

• For AWS this is the AWS Account ID
• For Azure this is the Subscription ID
• For GCP its the Service Account

In case of chalk running in the cloud, the region in which chalk executes in

In case of chalk running in the cloud, the public IPv4 of the host in which chalk executes in

In case of chalk running in the cloud, the instance type where chalk executes in (e.g., t2.medium for AWS)

In case of chalk running in the cloud, tags associated with the instance

In case of chalk running in the cloud, the type of the service the node is running in, (eks, ecs for AWS etc.)

This functionality is currently experimental, and only EKS, EC2, ECS are inferred for AWS.

JSON containing cloud instance attributes, such as instance-id, IP addresses, etc.

See https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service for more

JSON containing cloud instance attributes, such as instance-id, IP addresses, etc.

See https://cloud.google.com/compute/docs/metadata/overview for more

JSON containing instance attributes, such as instance-id, private IP address, etc. See Instance identity documents.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

Used to verify the document's authenticity and content against the signature. See Instance identity documents.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

Data that can be used by other parties to verify identity document's origin and authenticity. See Instance identity documents.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

Value showing whether the customer has enabled detailed one-minute monitoring in CloudWatch. Valid values: enabled, disabled.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The AMI ID used to launch the instance.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

If you started more than one instance at the same time, this value indicates the order in which the instance was launched. The value of the first instance launched is 0.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The path to the AMI manifest file in Amazon S3. If you used an Amazon EBS-backed AMI to launch the instance, the returned result is unknown.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The AMI IDs of any instances that were rebundled to create this AMI. This value will only exist if the AMI manifest file contained an ancestor-amis key.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

If the EC2 instance is using IP-based naming (IPBN), this is the private IPv4 DNS hostname of the instance. If the EC2 instance is using Resource-based naming (RBN), this is the RBN. In cases where multiple network interfaces are present, this refers to the eth0 device (the device for which the device number is 0). For more information about IPBN and RBN, see Amazon EC2 instance hostname types.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

If there is an IAM role associated with the instance, contains information about the last time the instance profile was updated, including the instance's LastUpdated date, InstanceProfileArn, and InstanceProfileId. Otherwise, not present.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The ID of an AWS instance.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The purchasing option of this instance. For more information see:

• https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The type of instance. For more information, see:

• https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The IPv6 address of the instance, if any. In cases where multiple network interfaces are present, this refers to the eth0 device network interface and the first IPv6 address assigned.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The ID of the kernel launched with this instance, if applicable.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

In cases where multiple network interfaces are present, this refers to the eth0 device (the device for which the device number is 0). If the EC2 instance is using IP-based naming (IPBN), this is the private IPv4 DNS hostname of the instance. If the EC2 instance is using Resource-based naming (RBN), this is the RBN. For more information about IPBN, RBN, and EC2 instance naming, see:

• https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The private IPv4 address of the instance, if any. In cases where multiple network interfaces are present, this refers to the eth0 device (the device for which the device number is 0).

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The Availability Zone in which the instance launched.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The static Availability Zone ID in which the instance is launched. The Availability Zone ID is consistent across accounts. However, it might be different from the Availability Zone, which can vary by account.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The name of the placement group in which the instance is launched.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The ID of the host on which the instance is launched. Applicable only to Dedicated Hosts.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The number of the partition in which the instance is launched.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The AWS Region in which the instance is launched.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The instance's public DNS (IPv4). This category is only returned if the enableDnsHostnames attribute is set to true. For more information, see DNS attributes for your VPC in the Amazon VPC User Guide. If the instance only has a public-IPv6 address and no public-IPv4 address, this item is not set.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The public IPv4 address. If an Elastic IP address is associated with the instance, the value returned is the Elastic IP address.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

Public key for SSH access. Only available if supplied at instance launch time.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The names of the security groups applied to the instance.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The IDs of the security groups to which the network interface belongs.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The domain for AWS resources for the Region.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The partition that the resource is in. For standard AWS Regions, the partition is aws. If you have resources in other partitions, the partition is aws-partitionname. For example, the partition for resources in the China (Beijing) Region is aws-cn.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The instance tags associated with the instance. Only available if you explicitly allow access to tags in instance metadata. For more information, see Allow access to tags in instance metadata.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

Value showing the target Auto Scaling lifecycle state that an Auto Scaling instance is transitioning to. Present when the instance transitions to one of the target lifecycle states after March 10, 2022. Possible values: Detached | InService | Standby | Terminated | Warmed:Hibernated | Warmed:Running | Warmed:Stopped | Warmed:Terminated. See Retrieve the target lifecycle state through instance metadata in the Amazon EC2 Auto Scaling User Guide.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The virtual device that contains the root/boot file system.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The virtual devices or partitions associated with the root devices or partitions on the virtual device, where the root (/ or C:) file system is associated with the given instance.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The virtual devices associated with swap. Not always present.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

If there are completed or canceled maintenance events for the instance, contains a JSON string with information about the events. For more information, see To view event history about completed or canceled events.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

If there are active maintenance events for the instance, contains a JSON string with information about the events. For more information, see View scheduled events.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The approximate time, in UTC, when the EC2 instance rebalance recommendation notification is emitted for the instance. The following is an example of the metadata for this category: {"noticeTime": "2020-11-05T08:22:00Z"}. This category is available only after the notification is emitted. For more information, see EC2 instance rebalance recommendations.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

Information about the credentials in identity-credentials/ec2/security-credentials/ec2-instance.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

Credentials for the instance identity role that allow on-instance software to identify itself to AWS to support features such as EC2 Instance Connect and AWS Systems Manager Default Host Management Configuration. These credentials have no policies attached, so they have no additional AWS API permissions beyond identifying the instance to the AWS feature. This option will not log the SecretAccessKey and Token.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

Notifies the instance that it should reboot in preparation for bundling. Valid values: none | shutdown | bundle-pending.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The instance's media access control (MAC) address. In cases where multiple network interfaces are present, this refers to the eth0 device (the device for which the device number is 0).

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The ID of the network interface.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The ID of the subnet in which the interface resides.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The ID of the VPC in which the interface resides.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

No longer available.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

AWS Marketplace product codes associated with the instance, if any.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The ID of the RAM disk specified at launch time, if applicable.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The ID of the reservation.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The action (hibernate, stop, or terminate) and the approximate time, in UTC, when the action will occur. This item is present only if the Spot Instance has been marked for hibernate, stop, or terminate. For more information, see instance-action.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

The approximate time, in UTC, that the operating system for your Spot Instance will receive the shutdown signal. This item is present and contains a time value (for example, 2015-01-05T18:02:00Z) only if the Spot Instance has been marked for termination by Amazon EC2. The termination-time item is not set to a time if you terminated the Spot Instance yourself. For more information, see termination-time.

This key is only available as a run-time key, and only when running in AWS where imdsv2 is available.

An audit trail of any actions taken by the config file that involved the world beyond the chalk process. For instance, any file modifications and web connections get audited, as do externally run commands.

Calculates the amount of time between the start of a chalk executable and when a report is generated. It's an integer with resolution of 1/1000000th of a second.

This key is only used with chalk executables. It holds the embedded configuration for that instance of the chalk command.

Chalk executables can only have their configuration changed via the chalk config command, or chalk setup.

Added to chalk binaries to indicate the implementation of Chalk in use.

Count how many times the self-mark has been rewritten.

Used for attestations.

Also necessary for attestations.

API key used to optionally save/load attestation keys to cloud.

Key to hold the OIDC refresh token for non-user present API re-authentication.

...

...

This is where we save configuration parameters for components that have been imported.

The items in the list consist of five-tuples:

1. A boolean indicating whether it's an attribute parameter (false means it's a variable parameter)
2. The base URL reference for the component
3. The name of the variable or attribute.
4. The Con4m type of the parameter.
5. The stored value (which will be of the type provided)

This consists of URLs (minus the file extension) mapped to source code for components.