# Documentation
## Docs
- [Access Tokens](https://docs.chkk.io/administration/access-tokens.md): Administration instructions for using and managing Access Tokens
- [Multi-Org Support](https://docs.chkk.io/administration/multi-org-support.md): Administration instructions for managing users in multiple Organizations
- [Organization Settings](https://docs.chkk.io/administration/organization-settings.md): Administration instructions for managing Organization Settings
- [Plan and Usage](https://docs.chkk.io/administration/plan-and-usage.md): Administration instructions for plan usage management
- [User Management](https://docs.chkk.io/administration/user-management.md): Administration instructions for managing users
- [Chkk MCP Server](https://docs.chkk.io/ai/chkk-mcp-servers.md): Connect MCP Clients (e.g., Cursor, Claude Desktop) to Chkk Risk Analysis
- [llms.txt](https://docs.chkk.io/ai/llms-txt.md): Allow your LLMs to read and index Chkk context
- [Introduction](https://docs.chkk.io/api-reference/introduction.md)
- [Get Access Token](https://docs.chkk.io/api-reference/v1/login/get-access-token.md): Authenticate and obtain access credentials for authorized operations.
- [Get a specific Risk](https://docs.chkk.io/api-reference/v1/risk/get-a-specific-risk.md): Returns the full details of a single Risk.
- [List resources for a specific Risk](https://docs.chkk.io/api-reference/v1/risk/list-resources-for-a-specific-risk.md): Returns a paginated list of Kubernetes resources that are associated with the specified Operational Risk.
- [List Risks](https://docs.chkk.io/api-reference/v1/risk/list-risks.md): List Risks matching one or more filter parameters.
- [Create Account](https://docs.chkk.io/api-reference/v2/account/create-account.md): Create a new Account
An Account is a container for resource ownership. Organizations can
have multiple Accounts, each representing a department or division of the
Organization that has ownership over some segment of the Organization's
resources.
Accounts are uniquely identified by a UUID, prefixed with the string
ac_, for example ac_c42014e7-baf5-4ec6-a502-858f98dca7c8
- [Delete Account](https://docs.chkk.io/api-reference/v2/account/delete-account.md): Delete a Account
An Account is a container for resource ownership. Organizations can
have multiple Accounts, each representing a department or division of the
Organization that has ownership over some segment of the Organization's
resources.
Accounts are uniquely identified by a UUID, prefixed with the string
ac_, for example ac_c42014e7-baf5-4ec6-a502-858f98dca7c8
- [Get Account](https://docs.chkk.io/api-reference/v2/account/get-account.md): Gets a single Account
An Account is a container for resource ownership. Organizations can
have multiple Accounts, each representing a department or division of the
Organization that has ownership over some segment of the Organization's
resources.
Accounts are uniquely identified by a UUID, prefixed with the string
ac_, for example ac_c42014e7-baf5-4ec6-a502-858f98dca7c8
- [List Accounts](https://docs.chkk.io/api-reference/v2/account/list-accounts.md): List multiple Accounts
An Account is a container for resource ownership. Organizations can
have multiple Accounts, each representing a department or division of the
Organization that has ownership over some segment of the Organization's
resources.
Accounts are uniquely identified by a UUID, prefixed with the string
ac_, for example ac_c42014e7-baf5-4ec6-a502-858f98dca7c8
- [Update Account](https://docs.chkk.io/api-reference/v2/account/update-account.md): Update an existing Account
An Account is a container for resource ownership. Organizations can
have multiple Accounts, each representing a department or division of the
Organization that has ownership over some segment of the Organization's
resources.
Accounts are uniquely identified by a UUID, prefixed with the string
ac_, for example ac_c42014e7-baf5-4ec6-a502-858f98dca7c8
- [Create Container](https://docs.chkk.io/api-reference/v2/kubecluster/create-container.md): Create a new KubeClusterResourceContainer
A KubeClusterResource can have many KubeClusterResourceContainers.
When a KubeClusterResource refers to a Kubernetes Resource that is comprised of
one or more Kubernetes ContainerSpecs, we create a KubeClusterResourceContainer
corresponding to that ContainerSpec. This allows us to have fine-grained
knowledge of the specific Images referenced in all Kubernetes Resources in the
KubeCluster.
A KubeClusterResourceContainer may be associated with a known Project.
When the KubeClusterResourceContainer's Project field is empty, that means that
the classification process was unable to determine a matching Project for the
discovered Kubernetes Resource Container.
A KubeClusterResourceContainer may be associated with a known
ProjectContainer. When the KubeClusterResourceContainer's ProjectContainer
field is empty, that means that the classification process was unable to
determine a matching ProjectContainer for the discovered Kubernetes Resource
Container.
- [Create KubeCluster](https://docs.chkk.io/api-reference/v2/kubecluster/create-kubecluster.md): Create a new KubeCluster
A KubeCluster describes a single Kubernetes cluster provisioned by a
KubePlatform.
A KubeCluster is uniquely identified by slugified name that is unique within
the set of KubeCluster name for an Account, e.g. cluster1 or
k8scl_552fb09a-5a6a-4530-86d3-bcc0a770024d.
KubeClusters always have an Environment tag that is defined by the
customer and allows the customer to categorize their KubeClusters.
The Version field of a KubeCluster indicates the current
Kubernetes control plane version.
- [Delete Container](https://docs.chkk.io/api-reference/v2/kubecluster/delete-container.md): Delete a KubeClusterResourceContainer
A KubeClusterResource can have many KubeClusterResourceContainers.
When a KubeClusterResource refers to a Kubernetes Resource that is comprised of
one or more Kubernetes ContainerSpecs, we create a KubeClusterResourceContainer
corresponding to that ContainerSpec. This allows us to have fine-grained
knowledge of the specific Images referenced in all Kubernetes Resources in the
KubeCluster.
A KubeClusterResourceContainer may be associated with a known Project.
When the KubeClusterResourceContainer's Project field is empty, that means that
the classification process was unable to determine a matching Project for the
discovered Kubernetes Resource Container.
A KubeClusterResourceContainer may be associated with a known
ProjectContainer. When the KubeClusterResourceContainer's ProjectContainer
field is empty, that means that the classification process was unable to
determine a matching ProjectContainer for the discovered Kubernetes Resource
Container.
- [Delete KubeCluster](https://docs.chkk.io/api-reference/v2/kubecluster/delete-kubecluster.md): Delete a KubeCluster
A KubeCluster describes a single Kubernetes cluster provisioned by a
KubePlatform.
A KubeCluster is uniquely identified by slugified name that is unique within
the set of KubeCluster name for an Account, e.g. cluster1 or
k8scl_552fb09a-5a6a-4530-86d3-bcc0a770024d.
KubeClusters always have an Environment tag that is defined by the
customer and allows the customer to categorize their KubeClusters.
The Version field of a KubeCluster indicates the current
Kubernetes control plane version.
- [Get Container](https://docs.chkk.io/api-reference/v2/kubecluster/get-container.md): Gets a single KubeClusterResourceContainer
A KubeClusterResource can have many KubeClusterResourceContainers.
When a KubeClusterResource refers to a Kubernetes Resource that is comprised of
one or more Kubernetes ContainerSpecs, we create a KubeClusterResourceContainer
corresponding to that ContainerSpec. This allows us to have fine-grained
knowledge of the specific Images referenced in all Kubernetes Resources in the
KubeCluster.
A KubeClusterResourceContainer may be associated with a known Project.
When the KubeClusterResourceContainer's Project field is empty, that means that
the classification process was unable to determine a matching Project for the
discovered Kubernetes Resource Container.
A KubeClusterResourceContainer may be associated with a known
ProjectContainer. When the KubeClusterResourceContainer's ProjectContainer
field is empty, that means that the classification process was unable to
determine a matching ProjectContainer for the discovered Kubernetes Resource
Container.
- [Get KubeCluster](https://docs.chkk.io/api-reference/v2/kubecluster/get-kubecluster.md): Gets a single KubeCluster
A KubeCluster describes a single Kubernetes cluster provisioned by a
KubePlatform.
A KubeCluster is uniquely identified by slugified name that is unique within
the set of KubeCluster name for an Account, e.g. cluster1 or
k8scl_552fb09a-5a6a-4530-86d3-bcc0a770024d.
KubeClusters always have an Environment tag that is defined by the
customer and allows the customer to categorize their KubeClusters.
The Version field of a KubeCluster indicates the current
Kubernetes control plane version.
- [Get Namespace](https://docs.chkk.io/api-reference/v2/kubecluster/get-namespace.md): Gets a single KubeClusterScanNamespace
A KubeClusterScan can have many KubeClusterScanNamespaces. Each unique
Kubernetes Namespace discovered for a KubeClusterScan is represented by a
unique KubeClusterScanNamespace record.
- [Get Resource](https://docs.chkk.io/api-reference/v2/kubecluster/get-resource.md): Gets a single KubeClusterResource
A KubeCluster can have many KubeClusterResources. Each time a
KubeCluster's inventory is scanned, one or more KubeClusterResources are
created for the KubeCluster and scan date.
KubeClusterResource represents a single Kubernetes Resource (Deployment,
Daemonset, StatefulSet, etc) installed in a specific Kubernetes Namespace in
the KubeCluster.
A KubeClusterResource may be assigned a known KubeDeploymentSystem.
When the KubeClusterResource's DeploymentSystem field is empty, that means that
the classification process was unable to determine a matching
KubeDeploymentSystem for the discovered Kubernetes Resource.
A KubeClusterResource may be assigned a known PackageSystem. When the
KubeClusterResource's PackageSystem field is empty, that means that the
classification process was unable to determine a matching PackageSystem for the
discovered Kubernetes Resource.
A KubeClusterResource may be associated with a known Package. When the
KubeClusterResource's Package field is empty, that means that the
classification process was unable to determine a matching Package for the
discovered Kubernetes Resource.
A KubeClusterResource may be associated with a known PackageComponent.
When the KubeClusterResource's PackageComponent field is empty, that means that
the classification process was unable to determine a matching PackageComponent
for the discovered Kubernetes Resource.
- [List Containers](https://docs.chkk.io/api-reference/v2/kubecluster/list-containers.md): List multiple KubeClusterResourceContainers
A KubeClusterResource can have many KubeClusterResourceContainers.
When a KubeClusterResource refers to a Kubernetes Resource that is comprised of
one or more Kubernetes ContainerSpecs, we create a KubeClusterResourceContainer
corresponding to that ContainerSpec. This allows us to have fine-grained
knowledge of the specific Images referenced in all Kubernetes Resources in the
KubeCluster.
A KubeClusterResourceContainer may be associated with a known Project.
When the KubeClusterResourceContainer's Project field is empty, that means that
the classification process was unable to determine a matching Project for the
discovered Kubernetes Resource Container.
A KubeClusterResourceContainer may be associated with a known
ProjectContainer. When the KubeClusterResourceContainer's ProjectContainer
field is empty, that means that the classification process was unable to
determine a matching ProjectContainer for the discovered Kubernetes Resource
Container.
- [List KubeClusters](https://docs.chkk.io/api-reference/v2/kubecluster/list-kubeclusters.md): List multiple KubeClusters
A KubeCluster describes a single Kubernetes cluster provisioned by a
KubePlatform.
A KubeCluster is uniquely identified by slugified name that is unique within
the set of KubeCluster name for an Account, e.g. cluster1 or
k8scl_552fb09a-5a6a-4530-86d3-bcc0a770024d.
KubeClusters always have an Environment tag that is defined by the
customer and allows the customer to categorize their KubeClusters.
The Version field of a KubeCluster indicates the current
Kubernetes control plane version.
- [List Namespaces](https://docs.chkk.io/api-reference/v2/kubecluster/list-namespaces.md): List multiple KubeClusterScanNamespaces
A KubeClusterScan can have many KubeClusterScanNamespaces. Each unique
Kubernetes Namespace discovered for a KubeClusterScan is represented by a
unique KubeClusterScanNamespace record.
- [List Resources](https://docs.chkk.io/api-reference/v2/kubecluster/list-resources.md): List multiple KubeClusterResources
A KubeCluster can have many KubeClusterResources. Each time a
KubeCluster's inventory is scanned, one or more KubeClusterResources are
created for the KubeCluster and scan date.
KubeClusterResource represents a single Kubernetes Resource (Deployment,
Daemonset, StatefulSet, etc) installed in a specific Kubernetes Namespace in
the KubeCluster.
A KubeClusterResource may be assigned a known KubeDeploymentSystem.
When the KubeClusterResource's DeploymentSystem field is empty, that means that
the classification process was unable to determine a matching
KubeDeploymentSystem for the discovered Kubernetes Resource.
A KubeClusterResource may be assigned a known PackageSystem. When the
KubeClusterResource's PackageSystem field is empty, that means that the
classification process was unable to determine a matching PackageSystem for the
discovered Kubernetes Resource.
A KubeClusterResource may be associated with a known Package. When the
KubeClusterResource's Package field is empty, that means that the
classification process was unable to determine a matching Package for the
discovered Kubernetes Resource.
A KubeClusterResource may be associated with a known PackageComponent.
When the KubeClusterResource's PackageComponent field is empty, that means that
the classification process was unable to determine a matching PackageComponent
for the discovered Kubernetes Resource.
- [List Scans](https://docs.chkk.io/api-reference/v2/kubecluster/list-scans.md): List multiple KubeClusterScans
A KubeClusterScan represents a single scan of a Kubernetes cluster.
- [Update Container](https://docs.chkk.io/api-reference/v2/kubecluster/update-container.md): Update an existing KubeClusterResourceContainer
A KubeClusterResource can have many KubeClusterResourceContainers.
When a KubeClusterResource refers to a Kubernetes Resource that is comprised of
one or more Kubernetes ContainerSpecs, we create a KubeClusterResourceContainer
corresponding to that ContainerSpec. This allows us to have fine-grained
knowledge of the specific Images referenced in all Kubernetes Resources in the
KubeCluster.
A KubeClusterResourceContainer may be associated with a known Project.
When the KubeClusterResourceContainer's Project field is empty, that means that
the classification process was unable to determine a matching Project for the
discovered Kubernetes Resource Container.
A KubeClusterResourceContainer may be associated with a known
ProjectContainer. When the KubeClusterResourceContainer's ProjectContainer
field is empty, that means that the classification process was unable to
determine a matching ProjectContainer for the discovered Kubernetes Resource
Container.
- [Update KubeCluster](https://docs.chkk.io/api-reference/v2/kubecluster/update-kubecluster.md): Update an existing KubeCluster
A KubeCluster describes a single Kubernetes cluster provisioned by a
KubePlatform.
A KubeCluster is uniquely identified by slugified name that is unique within
the set of KubeCluster name for an Account, e.g. cluster1 or
k8scl_552fb09a-5a6a-4530-86d3-bcc0a770024d.
KubeClusters always have an Environment tag that is defined by the
customer and allows the customer to categorize their KubeClusters.
The Version field of a KubeCluster indicates the current
Kubernetes control plane version.
- [Create KubePlatform](https://docs.chkk.io/api-reference/v2/kubeplatform/create-kubeplatform.md): Create a new KubePlatform
A KubePlatform describes things like the cloud infrastructure provider and the
Kubernetes control plane provider.
An Organization can have one or more KubePlatforms.
- [Delete KubePlatform](https://docs.chkk.io/api-reference/v2/kubeplatform/delete-kubeplatform.md): Delete a KubePlatform
A KubePlatform describes things like the cloud infrastructure provider and the
Kubernetes control plane provider.
An Organization can have one or more KubePlatforms.
- [Get KubePlatform](https://docs.chkk.io/api-reference/v2/kubeplatform/get-kubeplatform.md): Gets a single KubePlatform
A KubePlatform describes things like the cloud infrastructure provider and the
Kubernetes control plane provider.
An Organization can have one or more KubePlatforms.
- [List KubePlatforms](https://docs.chkk.io/api-reference/v2/kubeplatform/list-kubeplatforms.md): List multiple KubePlatforms
A KubePlatform describes things like the cloud infrastructure provider and the
Kubernetes control plane provider.
An Organization can have one or more KubePlatforms.
- [Update KubePlatform](https://docs.chkk.io/api-reference/v2/kubeplatform/update-kubeplatform.md): Update an existing KubePlatform
A KubePlatform describes things like the cloud infrastructure provider and the
Kubernetes control plane provider.
An Organization can have one or more KubePlatforms.
- [Create Artifact](https://docs.chkk.io/api-reference/v2/oci/create-artifact.md): Create a new OCIArtifact
An OCIArtifact is a single OCI Artifact (manifest) that describes an OCI
Image or other OCI Artifact.
OCIArtifacts have a MediaType that informs you what the OCIArtifact
contains. For OCIArtifacts with a MediaType of
application/vnd.oci.image.manifest.v1+json or
application/vnd.docker.container.image.v1+json, the Architecture
field will show the compute architecture that the OCI Image was built for (e.g.
"amd64")
OCIArtifacts can be associated with zero or more ProjectReleases and
PackageReleases.
- [Create Reference](https://docs.chkk.io/api-reference/v2/oci/create-reference.md): Create a new OCIReference
An OCIReference represents a relationship between an OCITag and an
OCIArtifact.
When attempting to match a customer's container image to a known
OCIArtifact, we look up an OCITag that matches a particular digest. For
mutable OCITags, that digest association, however, changes over time. Until
OCIReference was introduced, we were only storing the first known
digest for these mutable tags, which ended up introducing a lot of stale
data into the digest classification process: the classifiers were not able
to find OCITags that match newer digests for these mutable tags and
therefore less accurate classifiers like ruleset and deduction classifier
needed to try and classify the cluster inventory record.
For OCITags that are mutable -- e.g. "latest" or "stable" or "v1" -- there
can be many digests that an OCITag has previously pointed to.
Previously-referred digests for an OCITag are made available through the
OCIReference object model. You may be wondering why we don't have an
References field on OCITag that just returns the digests that have been
previously associated with this OCITag. The reason for that is because the
list of previously-known digest associations can be very long (it's
unbounded) and so having this information in a separately-fetched object
model that can be paginated/controlled seemed like a better design.
- [Create Repository](https://docs.chkk.io/api-reference/v2/oci/create-repository.md): Create a new OCIRepository
An OCIRepository represents a single namespace within an OCI Registry.
OCIRepositories are uniquely identified by a URI-like string where the final
path of the URI represents the OCIRepository Namespace and the part of the URI
before the Namespace is the Registry identifier.
Examples of OCIRepository identifiers:
* docker.io/istio/pilot: The pilot namespace in the docker.io/istio
registry.
* public.ecr.aws/bottlerocket/bottlerocket-operator: The
bottlerocket-operator namespace in the public.ecr.aws/bottlerocket
registry.
- [Create Tag](https://docs.chkk.io/api-reference/v2/oci/create-tag.md): Create a new OCITag
An OCIRepository can publish zero or more OCITags. OCITags are names that
point to a unique OCIArtifact digest.
An OCITag's ID is comprised of the OCIRepository ID followed by a : and the
Tag name.
Examples of OCITag identifiers:
* docker.io/istio/pilot:1.3.0: The 1.3.0 tag on the docker.io/istio/pilot
OCIRepository.
* public.ecr.aws/bottlerocket/bottlerocket-operator:0.1: The 0.1 tag on the
public.ecr.aws/bottlerocket/bottlerocket-operator OCIRepository.
- [Delete Artifact](https://docs.chkk.io/api-reference/v2/oci/delete-artifact.md): Delete a OCIArtifact
An OCIArtifact is a single OCI Artifact (manifest) that describes an OCI
Image or other OCI Artifact.
OCIArtifacts have a MediaType that informs you what the OCIArtifact
contains. For OCIArtifacts with a MediaType of
application/vnd.oci.image.manifest.v1+json or
application/vnd.docker.container.image.v1+json, the Architecture
field will show the compute architecture that the OCI Image was built for (e.g.
"amd64")
OCIArtifacts can be associated with zero or more ProjectReleases and
PackageReleases.
- [Delete Reference](https://docs.chkk.io/api-reference/v2/oci/delete-reference.md): Delete an OCIReference
An OCIReference represents a relationship between an OCITag and an
OCIArtifact.
When attempting to match a customer's container image to a known
OCIArtifact, we look up an OCITag that matches a particular digest. For
mutable OCITags, that digest association, however, changes over time. Until
OCIReference was introduced, we were only storing the first known
digest for these mutable tags, which ended up introducing a lot of stale
data into the digest classification process: the classifiers were not able
to find OCITags that match newer digests for these mutable tags and
therefore less accurate classifiers like ruleset and deduction classifier
needed to try and classify the cluster inventory record.
For OCITags that are mutable -- e.g. "latest" or "stable" or "v1" -- there
can be many digests that an OCITag has previously pointed to.
Previously-referred digests for an OCITag are made available through the
OCIReference object model. You may be wondering why we don't have an
References field on OCITag that just returns the digests that have been
previously associated with this OCITag. The reason for that is because the
list of previously-known digest associations can be very long (it's
unbounded) and so having this information in a separately-fetched object
model that can be paginated/controlled seemed like a better design.
- [Delete Repository](https://docs.chkk.io/api-reference/v2/oci/delete-repository.md): Delete an OCIRepository
An OCIRepository represents a single namespace within an OCI Registry.
OCIRepositories are uniquely identified by a URI-like string where the final
path of the URI represents the OCIRepository Namespace and the part of the URI
before the Namespace is the Registry identifier.
Examples of OCIRepository identifiers:
* docker.io/istio/pilot: The pilot namespace in the docker.io/istio
registry.
* public.ecr.aws/bottlerocket/bottlerocket-operator: The
bottlerocket-operator namespace in the public.ecr.aws/bottlerocket
registry.
- [Delete Tag](https://docs.chkk.io/api-reference/v2/oci/delete-tag.md): Delete a OCITag
An OCIRepository can publish zero or more OCITags. OCITags are names that
point to a unique OCIArtifact digest.
An OCITag's ID is comprised of the OCIRepository ID followed by a : and the
Tag name.
Examples of OCITag identifiers:
* docker.io/istio/pilot:1.3.0: The 1.3.0 tag on the docker.io/istio/pilot
OCIRepository.
* public.ecr.aws/bottlerocket/bottlerocket-operator:0.1: The 0.1 tag on the
public.ecr.aws/bottlerocket/bottlerocket-operator OCIRepository.
- [Get Artifact](https://docs.chkk.io/api-reference/v2/oci/get-artifact.md): Gets a single OCIArtifact
An OCIArtifact is a single OCI Artifact (manifest) that describes an OCI
Image or other OCI Artifact.
OCIArtifacts have a MediaType that informs you what the OCIArtifact
contains. For OCIArtifacts with a MediaType of
application/vnd.oci.image.manifest.v1+json or
application/vnd.docker.container.image.v1+json, the Architecture
field will show the compute architecture that the OCI Image was built for (e.g.
"amd64")
OCIArtifacts can be associated with zero or more ProjectReleases and
PackageReleases.
- [Get Reference](https://docs.chkk.io/api-reference/v2/oci/get-reference.md): Gets a single OCIReference
An OCIReference represents a relationship between an OCITag and an
OCIArtifact.
When attempting to match a customer's container image to a known
OCIArtifact, we look up an OCITag that matches a particular digest. For
mutable OCITags, that digest association, however, changes over time. Until
OCIReference was introduced, we were only storing the first known
digest for these mutable tags, which ended up introducing a lot of stale
data into the digest classification process: the classifiers were not able
to find OCITags that match newer digests for these mutable tags and
therefore less accurate classifiers like ruleset and deduction classifier
needed to try and classify the cluster inventory record.
For OCITags that are mutable -- e.g. "latest" or "stable" or "v1" -- there
can be many digests that an OCITag has previously pointed to.
Previously-referred digests for an OCITag are made available through the
OCIReference object model. You may be wondering why we don't have an
References field on OCITag that just returns the digests that have been
previously associated with this OCITag. The reason for that is because the
list of previously-known digest associations can be very long (it's
unbounded) and so having this information in a separately-fetched object
model that can be paginated/controlled seemed like a better design.
- [Get Repository](https://docs.chkk.io/api-reference/v2/oci/get-repository.md): Gets a single OCIRepository
An OCIRepository represents a single namespace within an OCI Registry.
OCIRepositories are uniquely identified by a URI-like string where the final
path of the URI represents the OCIRepository Namespace and the part of the URI
before the Namespace is the Registry identifier.
Examples of OCIRepository identifiers:
* docker.io/istio/pilot: The pilot namespace in the docker.io/istio
registry.
* public.ecr.aws/bottlerocket/bottlerocket-operator: The
bottlerocket-operator namespace in the public.ecr.aws/bottlerocket
registry.
- [Get Tag](https://docs.chkk.io/api-reference/v2/oci/get-tag.md): Gets a single OCITag
An OCIRepository can publish zero or more OCITags. OCITags are names that
point to a unique OCIArtifact digest.
An OCITag's ID is comprised of the OCIRepository ID followed by a : and the
Tag name.
Examples of OCITag identifiers:
* docker.io/istio/pilot:1.3.0: The 1.3.0 tag on the docker.io/istio/pilot
OCIRepository.
* public.ecr.aws/bottlerocket/bottlerocket-operator:0.1: The 0.1 tag on the
public.ecr.aws/bottlerocket/bottlerocket-operator OCIRepository.
- [List Artifacts](https://docs.chkk.io/api-reference/v2/oci/list-artifacts.md): List multiple OCIArtifacts
An OCIArtifact is a single OCI Artifact (manifest) that describes an OCI
Image or other OCI Artifact.
OCIArtifacts have a MediaType that informs you what the OCIArtifact
contains. For OCIArtifacts with a MediaType of
application/vnd.oci.image.manifest.v1+json or
application/vnd.docker.container.image.v1+json, the Architecture
field will show the compute architecture that the OCI Image was built for (e.g.
"amd64")
OCIArtifacts can be associated with zero or more ProjectReleases and
PackageReleases.
- [List Repositories](https://docs.chkk.io/api-reference/v2/oci/list-repositories.md): List multiple OCIRepositories
An OCIRepository represents a single namespace within an OCI Registry.
OCIRepositories are uniquely identified by a URI-like string where the final
path of the URI represents the OCIRepository Namespace and the part of the URI
before the Namespace is the Registry identifier.
Examples of OCIRepository identifiers:
* docker.io/istio/pilot: The pilot namespace in the docker.io/istio
registry.
* public.ecr.aws/bottlerocket/bottlerocket-operator: The
bottlerocket-operator namespace in the public.ecr.aws/bottlerocket
registry.
- [List Tags](https://docs.chkk.io/api-reference/v2/oci/list-tags.md): List multiple OCITags
An OCIReference represents a relationship between an OCITag and an
OCIArtifact.
When attempting to match a customer's container image to a known
OCIArtifact, we look up an OCITag that matches a particular digest. For
mutable OCITags, that digest association, however, changes over time. Until
OCIReference was introduced, we were only storing the first known
digest for these mutable tags, which ended up introducing a lot of stale
data into the digest classification process: the classifiers were not able
to find OCITags that match newer digests for these mutable tags and
therefore less accurate classifiers like ruleset and deduction classifier
needed to try and classify the cluster inventory record.
For OCITags that are mutable -- e.g. "latest" or "stable" or "v1" -- there
can be many digests that an OCITag has previously pointed to.
Previously-referred digests for an OCITag are made available through the
OCIReference object model. You may be wondering why we don't have an
References field on OCITag that just returns the digests that have been
previously associated with this OCITag. The reason for that is because the
list of previously-known digest associations can be very long (it's
unbounded) and so having this information in a separately-fetched object
model that can be paginated/controlled seemed like a better design.
- [List Tags](https://docs.chkk.io/api-reference/v2/oci/list-tags-1.md): List multiple OCITags
An OCIRepository can publish zero or more OCITags. OCITags are names that
point to a unique OCIArtifact digest.
An OCITag's ID is comprised of the OCIRepository ID followed by a : and the
Tag name.
Examples of OCITag identifiers:
* docker.io/istio/pilot:1.3.0: The 1.3.0 tag on the docker.io/istio/pilot
OCIRepository.
* public.ecr.aws/bottlerocket/bottlerocket-operator:0.1: The 0.1 tag on the
public.ecr.aws/bottlerocket/bottlerocket-operator OCIRepository.
- [Update Artifact](https://docs.chkk.io/api-reference/v2/oci/update-artifact.md): Update an existing OCIArtifact
An OCIArtifact is a single OCI Artifact (manifest) that describes an OCI
Image or other OCI Artifact.
OCIArtifacts have a MediaType that informs you what the OCIArtifact
contains. For OCIArtifacts with a MediaType of
application/vnd.oci.image.manifest.v1+json or
application/vnd.docker.container.image.v1+json, the Architecture
field will show the compute architecture that the OCI Image was built for (e.g.
"amd64")
OCIArtifacts can be associated with zero or more ProjectReleases and
PackageReleases.
- [Update Reference](https://docs.chkk.io/api-reference/v2/oci/update-reference.md): Update an existing OCIReference
An OCIReference represents a relationship between an OCITag and an
OCIArtifact.
When attempting to match a customer's container image to a known
OCIArtifact, we look up an OCITag that matches a particular digest. For
mutable OCITags, that digest association, however, changes over time. Until
OCIReference was introduced, we were only storing the first known
digest for these mutable tags, which ended up introducing a lot of stale
data into the digest classification process: the classifiers were not able
to find OCITags that match newer digests for these mutable tags and
therefore less accurate classifiers like ruleset and deduction classifier
needed to try and classify the cluster inventory record.
For OCITags that are mutable -- e.g. "latest" or "stable" or "v1" -- there
can be many digests that an OCITag has previously pointed to.
Previously-referred digests for an OCITag are made available through the
OCIReference object model. You may be wondering why we don't have an
References field on OCITag that just returns the digests that have been
previously associated with this OCITag. The reason for that is because the
list of previously-known digest associations can be very long (it's
unbounded) and so having this information in a separately-fetched object
model that can be paginated/controlled seemed like a better design.
- [Update Repository](https://docs.chkk.io/api-reference/v2/oci/update-repository.md): Update an existing OCIRepository
An OCIRepository represents a single namespace within an OCI Registry.
OCIRepositories are uniquely identified by a URI-like string where the final
path of the URI represents the OCIRepository Namespace and the part of the URI
before the Namespace is the Registry identifier.
Examples of OCIRepository identifiers:
* docker.io/istio/pilot: The pilot namespace in the docker.io/istio
registry.
* public.ecr.aws/bottlerocket/bottlerocket-operator: The
bottlerocket-operator namespace in the public.ecr.aws/bottlerocket
registry.
- [Update Tag](https://docs.chkk.io/api-reference/v2/oci/update-tag.md): Update an existing OCITag
An OCIRepository can publish zero or more OCITags. OCITags are names that
point to a unique OCIArtifact digest.
An OCITag's ID is comprised of the OCIRepository ID followed by a : and the
Tag name.
Examples of OCITag identifiers:
* docker.io/istio/pilot:1.3.0: The 1.3.0 tag on the docker.io/istio/pilot
OCIRepository.
* public.ecr.aws/bottlerocket/bottlerocket-operator:0.1: The 0.1 tag on the
public.ecr.aws/bottlerocket/bottlerocket-operator OCIRepository.
- [Create Organization](https://docs.chkk.io/api-reference/v2/organization/create-organization.md): Create a new Organization
An Organization is the top-level object that models a Chkk customer.
Organizations are uniquely identified by a UUID, prefixed with the string
org_, for example org_c42014e7-baf5-4ec6-a502-858f98dca7c8
- [Delete Organization](https://docs.chkk.io/api-reference/v2/organization/delete-organization.md): Delete a Organization
An Organization is the top-level object that models a Chkk customer.
Organizations are uniquely identified by a UUID, prefixed with the string
org_, for example org_c42014e7-baf5-4ec6-a502-858f98dca7c8
- [Get Organization](https://docs.chkk.io/api-reference/v2/organization/get-organization.md): Gets a single Organization
An Organization is the top-level object that models a Chkk customer.
Organizations are uniquely identified by a UUID, prefixed with the string
org_, for example org_c42014e7-baf5-4ec6-a502-858f98dca7c8
- [List Organizations](https://docs.chkk.io/api-reference/v2/organization/list-organizations.md): List multiple Organizations
An Organization is the top-level object that models a Chkk customer.
Organizations are uniquely identified by a UUID, prefixed with the string
org_, for example org_c42014e7-baf5-4ec6-a502-858f98dca7c8
- [Update Organization](https://docs.chkk.io/api-reference/v2/organization/update-organization.md): Update an existing Organization
An Organization is the top-level object that models a Chkk customer.
Organizations are uniquely identified by a UUID, prefixed with the string
org_, for example org_c42014e7-baf5-4ec6-a502-858f98dca7c8
- [Create Component](https://docs.chkk.io/api-reference/v2/package/create-component.md): Create a new PackageComponent
A Package has zero or more *PackageComponents*. A PackageComponent is a
separate Project, ProjectComponent, daemon, subsystem or binary distributed as
part of a PackageVersionSet.
A PackageComponent is uniquely identified by the combination of the
PackageVersionSet identifier and the Component name separated by a :
character. The Component name may be a Project identifier, a URL or
filepath-like identifier or just a string name.
Examples of PackageComponent identifiers:
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a:1:agent: The agent Component of
the first versionset (:1) of the Cilium Helm Chart Package specified by
that Package's UUID.
* helm-kube-prometheus-stack:3:prometheus-operator: The prometheus-operator
Component of the third versionset (:3) of the Kube Prometheus Helm Chart
Package specified by that Package's Alias (helm-kube-prometheus-stack)
> **IMPORTANT**: For Packages using the helm or kube PackageSystem, these
> PackageComponents represent a Kubernetes Resource (Deployment, DaemonSet
> or StatefulSet) that is installed by the Package.
Simple examples of PackageComponents would be the Bitnami Cert-Manager Helm
Chart Package's controller Deployment, the webhook Deployment and the
cainjector Deployment.
More complex examples of PackageComponents might be the ArgoCD Official
Upstream Helm Chart Package's extensive collection of controllers, caches and
persistent database storage components installed in Deployment, Daemonset and
StatefulSet resources.
- [Create Package](https://docs.chkk.io/api-reference/v2/package/create-package.md): Create a new Package
A Package is a named bundle of software that is bundled (and
identified) in the format of a specific PackageSystem.
A PackageSystem is an identifier of a packaging ecosystem.
Packages can use one of the following PackageSystems:
* helm for Helm charts
* kube for raw YAML manifests or Kustomize overlays that install one or
more Kubernetes resources
A Package is identified by a globally-unique ID field which is a UUID string
prefixed with the string 'pkg_', for example
'pkg_c42014e7-baf5-4ec6-a502-858f98dca7c8'.
A Package may be associated with one or more Projects and zero or more
ProjectComponents.
A Package may have one or more links associated with it. There are two types
of links that hold special significance to a package: 'package.archive' and
'package.source'. The 'package.archive' link is used to indicate the location
of the package's archive, which is the file that contains the package's
contents. The 'package.source' link is used to indicate a location on the web
where the package may be observed in an un-archived format. For example, the
cert-manager helm chart package can have the following links
- 'package.archive': https:charts.jetstack.io/cert-manager
- 'package.source': https:github.com/cert-manager/cert-manager/tree/master/deploy/charts/cert-manager
A Package may have zero or more aliases associated with it in the 'Aliases'
field. An alias for a Package is a human readable string that uniquely
identifies the Package.
A Package may be associated with one or more ProjectComponents. Packages with
PackageSystem helm or kube are associated with ProjectComponents
via the Package's collection of PackageComponents. A PackageComponent, which
corresponds to a specific Kubernetes Resource of Kind Deployment, DaemonSet or
StatefulSet, may reference one or more Docker Images. Those Docker Images
correspond to a ProjectComponent for one or more Projects.
- [Create Release](https://docs.chkk.io/api-reference/v2/package/create-release.md): Create a new PackageRelease
A Package may have one or more PackageReleases. A PackageRelease is
the coordinated publication of one or more Packages for the Package having the
same Version string.
A PackageRelease is uniquely identified by the combination of the Package UUID
or Package Alias and a version string separated by an @ character.
Example PackageRelease identifiers:
* helm-chkk-operator@0.0.13: the Chkk Operator Helm Chart Package Alias of
helm-chkk-operator with a version string of 0.0.13
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a@1.24.12: the Package UUID of the
Cilium Helm Chart and the version string 1.24.12
* helm-kube-prometheus-stack@65.4.0: the Kube Prometheus Helm Chart Package
Alias of helm-kube-prometheus-stack with a version string of 65.4.0
A PackageRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the PackageRelease.
- [Create VersionSet](https://docs.chkk.io/api-reference/v2/package/create-versionset.md): Create a new PackageVersionSet
A PackageVersionSet represents a configuration, layout or structure of
a Package that is consistent for a range of PackageReleases.
A PackageComponent is associated with a single PackageVersionSet. We track
changes to the componentry and structure of a Package over time using
PackageVersionSets.
PackageVersionSets are uniquely identified by the Package ID or Alias and
a simple integer, separated by a ':' character.
Examples of PackageVersionSet identifiers:
* argo-workflows:1: the first PackageVersionSet of the Argo Workflows
Package, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third PackageVersionSet of
the Argo Workflows Package, using the Argo Workflow Package's UUID as the
identifier.
Each PackageVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which PackageReleases the PackageVersionSet describes.
- [Delete Component](https://docs.chkk.io/api-reference/v2/package/delete-component.md): Delete a PackageComponent
A Package has zero or more *PackageComponents*. A PackageComponent is a
separate Project, ProjectComponent, daemon, subsystem or binary distributed as
part of a PackageVersionSet.
A PackageComponent is uniquely identified by the combination of the
PackageVersionSet identifier and the Component name separated by a :
character. The Component name may be a Project identifier, a URL or
filepath-like identifier or just a string name.
Examples of PackageComponent identifiers:
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a:1:agent: The agent Component of
the first versionset (:1) of the Cilium Helm Chart Package specified by
that Package's UUID.
* helm-kube-prometheus-stack:3:prometheus-operator: The prometheus-operator
Component of the third versionset (:3) of the Kube Prometheus Helm Chart
Package specified by that Package's Alias (helm-kube-prometheus-stack)
> **IMPORTANT**: For Packages using the helm or kube PackageSystem, these
> PackageComponents represent a Kubernetes Resource (Deployment, DaemonSet
> or StatefulSet) that is installed by the Package.
Simple examples of PackageComponents would be the Bitnami Cert-Manager Helm
Chart Package's controller Deployment, the webhook Deployment and the
cainjector Deployment.
More complex examples of PackageComponents might be the ArgoCD Official
Upstream Helm Chart Package's extensive collection of controllers, caches and
persistent database storage components installed in Deployment, Daemonset and
StatefulSet resources.
- [Delete Package](https://docs.chkk.io/api-reference/v2/package/delete-package.md): Delete a Package
A Package is a named bundle of software that is bundled (and
identified) in the format of a specific PackageSystem.
A PackageSystem is an identifier of a packaging ecosystem.
Packages can use one of the following PackageSystems:
* helm for Helm charts
* kube for raw YAML manifests or Kustomize overlays that install one or
more Kubernetes resources
A Package is identified by a globally-unique ID field which is a UUID string
prefixed with the string 'pkg_', for example
'pkg_c42014e7-baf5-4ec6-a502-858f98dca7c8'.
A Package may be associated with one or more Projects and zero or more
ProjectComponents.
A Package may have one or more links associated with it. There are two types
of links that hold special significance to a package: 'package.archive' and
'package.source'. The 'package.archive' link is used to indicate the location
of the package's archive, which is the file that contains the package's
contents. The 'package.source' link is used to indicate a location on the web
where the package may be observed in an un-archived format. For example, the
cert-manager helm chart package can have the following links
- 'package.archive': https:charts.jetstack.io/cert-manager
- 'package.source': https:github.com/cert-manager/cert-manager/tree/master/deploy/charts/cert-manager
A Package may have zero or more aliases associated with it in the 'Aliases'
field. An alias for a Package is a human readable string that uniquely
identifies the Package.
A Package may be associated with one or more ProjectComponents. Packages with
PackageSystem helm or kube are associated with ProjectComponents
via the Package's collection of PackageComponents. A PackageComponent, which
corresponds to a specific Kubernetes Resource of Kind Deployment, DaemonSet or
StatefulSet, may reference one or more Docker Images. Those Docker Images
correspond to a ProjectComponent for one or more Projects.
- [Delete Release](https://docs.chkk.io/api-reference/v2/package/delete-release.md): Delete a PackageRelease
A Package may have one or more PackageReleases. A PackageRelease is
the coordinated publication of one or more Packages for the Package having the
same Version string.
A PackageRelease is uniquely identified by the combination of the Package UUID
or Package Alias and a version string separated by an @ character.
Example PackageRelease identifiers:
* helm-chkk-operator@0.0.13: the Chkk Operator Helm Chart Package Alias of
helm-chkk-operator with a version string of 0.0.13
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a@1.24.12: the Package UUID of the
Cilium Helm Chart and the version string 1.24.12
* helm-kube-prometheus-stack@65.4.0: the Kube Prometheus Helm Chart Package
Alias of helm-kube-prometheus-stack with a version string of 65.4.0
A PackageRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the PackageRelease.
- [Delete VersionSet](https://docs.chkk.io/api-reference/v2/package/delete-versionset.md): Delete a PackageVersionSet
A PackageVersionSet represents a configuration, layout or structure of
a Package that is consistent for a range of PackageReleases.
A PackageComponent is associated with a single PackageVersionSet. We track
changes to the componentry and structure of a Package over time using
PackageVersionSets.
PackageVersionSets are uniquely identified by the Package ID or Alias and
a simple integer, separated by a ':' character.
Examples of PackageVersionSet identifiers:
* argo-workflows:1: the first PackageVersionSet of the Argo Workflows
Package, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third PackageVersionSet of
the Argo Workflows Package, using the Argo Workflow Package's UUID as the
identifier.
Each PackageVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which PackageReleases the PackageVersionSet describes.
- [Get Component](https://docs.chkk.io/api-reference/v2/package/get-component.md): Gets a single PackageComponent
A Package has zero or more *PackageComponents*. A PackageComponent is a
separate Project, ProjectComponent, daemon, subsystem or binary distributed as
part of a PackageVersionSet.
A PackageComponent is uniquely identified by the combination of the
PackageVersionSet identifier and the Component name separated by a :
character. The Component name may be a Project identifier, a URL or
filepath-like identifier or just a string name.
Examples of PackageComponent identifiers:
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a:1:agent: The agent Component of
the first versionset (:1) of the Cilium Helm Chart Package specified by
that Package's UUID.
* helm-kube-prometheus-stack:3:prometheus-operator: The prometheus-operator
Component of the third versionset (:3) of the Kube Prometheus Helm Chart
Package specified by that Package's Alias (helm-kube-prometheus-stack)
> **IMPORTANT**: For Packages using the helm or kube PackageSystem, these
> PackageComponents represent a Kubernetes Resource (Deployment, DaemonSet
> or StatefulSet) that is installed by the Package.
Simple examples of PackageComponents would be the Bitnami Cert-Manager Helm
Chart Package's controller Deployment, the webhook Deployment and the
cainjector Deployment.
More complex examples of PackageComponents might be the ArgoCD Official
Upstream Helm Chart Package's extensive collection of controllers, caches and
persistent database storage components installed in Deployment, Daemonset and
StatefulSet resources.
- [Get Package](https://docs.chkk.io/api-reference/v2/package/get-package.md): Gets a single Package
A Package is a named bundle of software that is bundled (and
identified) in the format of a specific PackageSystem.
A PackageSystem is an identifier of a packaging ecosystem.
Packages can use one of the following PackageSystems:
* helm for Helm charts
* kube for raw YAML manifests or Kustomize overlays that install one or
more Kubernetes resources
A Package is identified by a globally-unique ID field which is a UUID string
prefixed with the string 'pkg_', for example
'pkg_c42014e7-baf5-4ec6-a502-858f98dca7c8'.
A Package may be associated with one or more Projects and zero or more
ProjectComponents.
A Package may have one or more links associated with it. There are two types
of links that hold special significance to a package: 'package.archive' and
'package.source'. The 'package.archive' link is used to indicate the location
of the package's archive, which is the file that contains the package's
contents. The 'package.source' link is used to indicate a location on the web
where the package may be observed in an un-archived format. For example, the
cert-manager helm chart package can have the following links
- 'package.archive': https:charts.jetstack.io/cert-manager
- 'package.source': https:github.com/cert-manager/cert-manager/tree/master/deploy/charts/cert-manager
A Package may have zero or more aliases associated with it in the 'Aliases'
field. An alias for a Package is a human readable string that uniquely
identifies the Package.
A Package may be associated with one or more ProjectComponents. Packages with
PackageSystem helm or kube are associated with ProjectComponents
via the Package's collection of PackageComponents. A PackageComponent, which
corresponds to a specific Kubernetes Resource of Kind Deployment, DaemonSet or
StatefulSet, may reference one or more Docker Images. Those Docker Images
correspond to a ProjectComponent for one or more Projects.
- [Get Release](https://docs.chkk.io/api-reference/v2/package/get-release.md): Gets a single PackageRelease
A Package may have one or more PackageReleases. A PackageRelease is
the coordinated publication of one or more Packages for the Package having the
same Version string.
A PackageRelease is uniquely identified by the combination of the Package UUID
or Package Alias and a version string separated by an @ character.
Example PackageRelease identifiers:
* helm-chkk-operator@0.0.13: the Chkk Operator Helm Chart Package Alias of
helm-chkk-operator with a version string of 0.0.13
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a@1.24.12: the Package UUID of the
Cilium Helm Chart and the version string 1.24.12
* helm-kube-prometheus-stack@65.4.0: the Kube Prometheus Helm Chart Package
Alias of helm-kube-prometheus-stack with a version string of 65.4.0
A PackageRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the PackageRelease.
- [Get VersionSet](https://docs.chkk.io/api-reference/v2/package/get-versionset.md): Gets a single PackageVersionSet
A PackageVersionSet represents a configuration, layout or structure of
a Package that is consistent for a range of PackageReleases.
A PackageComponent is associated with a single PackageVersionSet. We track
changes to the componentry and structure of a Package over time using
PackageVersionSets.
PackageVersionSets are uniquely identified by the Package ID or Alias and
a simple integer, separated by a ':' character.
Examples of PackageVersionSet identifiers:
* argo-workflows:1: the first PackageVersionSet of the Argo Workflows
Package, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third PackageVersionSet of
the Argo Workflows Package, using the Argo Workflow Package's UUID as the
identifier.
Each PackageVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which PackageReleases the PackageVersionSet describes.
- [List Components](https://docs.chkk.io/api-reference/v2/package/list-components.md): List multiple PackageComponents
A Package has zero or more *PackageComponents*. A PackageComponent is a
separate Project, ProjectComponent, daemon, subsystem or binary distributed as
part of a PackageVersionSet.
A PackageComponent is uniquely identified by the combination of the
PackageVersionSet identifier and the Component name separated by a :
character. The Component name may be a Project identifier, a URL or
filepath-like identifier or just a string name.
Examples of PackageComponent identifiers:
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a:1:agent: The agent Component of
the first versionset (:1) of the Cilium Helm Chart Package specified by
that Package's UUID.
* helm-kube-prometheus-stack:3:prometheus-operator: The prometheus-operator
Component of the third versionset (:3) of the Kube Prometheus Helm Chart
Package specified by that Package's Alias (helm-kube-prometheus-stack)
> **IMPORTANT**: For Packages using the helm or kube PackageSystem, these
> PackageComponents represent a Kubernetes Resource (Deployment, DaemonSet
> or StatefulSet) that is installed by the Package.
Simple examples of PackageComponents would be the Bitnami Cert-Manager Helm
Chart Package's controller Deployment, the webhook Deployment and the
cainjector Deployment.
More complex examples of PackageComponents might be the ArgoCD Official
Upstream Helm Chart Package's extensive collection of controllers, caches and
persistent database storage components installed in Deployment, Daemonset and
StatefulSet resources.
- [List Packages](https://docs.chkk.io/api-reference/v2/package/list-packages.md): List multiple Packages
A Package is a named bundle of software that is bundled (and
identified) in the format of a specific PackageSystem.
A PackageSystem is an identifier of a packaging ecosystem.
Packages can use one of the following PackageSystems:
* helm for Helm charts
* kube for raw YAML manifests or Kustomize overlays that install one or
more Kubernetes resources
A Package is identified by a globally-unique ID field which is a UUID string
prefixed with the string 'pkg_', for example
'pkg_c42014e7-baf5-4ec6-a502-858f98dca7c8'.
A Package may be associated with one or more Projects and zero or more
ProjectComponents.
A Package may have one or more links associated with it. There are two types
of links that hold special significance to a package: 'package.archive' and
'package.source'. The 'package.archive' link is used to indicate the location
of the package's archive, which is the file that contains the package's
contents. The 'package.source' link is used to indicate a location on the web
where the package may be observed in an un-archived format. For example, the
cert-manager helm chart package can have the following links
- 'package.archive': https:charts.jetstack.io/cert-manager
- 'package.source': https:github.com/cert-manager/cert-manager/tree/master/deploy/charts/cert-manager
A Package may have zero or more aliases associated with it in the 'Aliases'
field. An alias for a Package is a human readable string that uniquely
identifies the Package.
A Package may be associated with one or more ProjectComponents. Packages with
PackageSystem helm or kube are associated with ProjectComponents
via the Package's collection of PackageComponents. A PackageComponent, which
corresponds to a specific Kubernetes Resource of Kind Deployment, DaemonSet or
StatefulSet, may reference one or more Docker Images. Those Docker Images
correspond to a ProjectComponent for one or more Projects.
- [List Releases](https://docs.chkk.io/api-reference/v2/package/list-releases.md): List multiple PackageReleases
A Package may have one or more PackageReleases. A PackageRelease is
the coordinated publication of one or more Packages for the Package having the
same Version string.
A PackageRelease is uniquely identified by the combination of the Package UUID
or Package Alias and a version string separated by an @ character.
Example PackageRelease identifiers:
* helm-chkk-operator@0.0.13: the Chkk Operator Helm Chart Package Alias of
helm-chkk-operator with a version string of 0.0.13
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a@1.24.12: the Package UUID of the
Cilium Helm Chart and the version string 1.24.12
* helm-kube-prometheus-stack@65.4.0: the Kube Prometheus Helm Chart Package
Alias of helm-kube-prometheus-stack with a version string of 65.4.0
A PackageRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the PackageRelease.
- [List VersionSets](https://docs.chkk.io/api-reference/v2/package/list-versionsets.md): List multiple PackageVersionSets
A PackageVersionSet represents a configuration, layout or structure of
a Package that is consistent for a range of PackageReleases.
A PackageComponent is associated with a single PackageVersionSet. We track
changes to the componentry and structure of a Package over time using
PackageVersionSets.
PackageVersionSets are uniquely identified by the Package ID or Alias and
a simple integer, separated by a ':' character.
Examples of PackageVersionSet identifiers:
* argo-workflows:1: the first PackageVersionSet of the Argo Workflows
Package, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third PackageVersionSet of
the Argo Workflows Package, using the Argo Workflow Package's UUID as the
identifier.
Each PackageVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which PackageReleases the PackageVersionSet describes.
- [Update Component](https://docs.chkk.io/api-reference/v2/package/update-component.md): Update an existing PackageComponent
A Package has zero or more *PackageComponents*. A PackageComponent is a
separate Project, ProjectComponent, daemon, subsystem or binary distributed as
part of a PackageVersionSet.
A PackageComponent is uniquely identified by the combination of the
PackageVersionSet identifier and the Component name separated by a :
character. The Component name may be a Project identifier, a URL or
filepath-like identifier or just a string name.
Examples of PackageComponent identifiers:
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a:1:agent: The agent Component of
the first versionset (:1) of the Cilium Helm Chart Package specified by
that Package's UUID.
* helm-kube-prometheus-stack:3:prometheus-operator: The prometheus-operator
Component of the third versionset (:3) of the Kube Prometheus Helm Chart
Package specified by that Package's Alias (helm-kube-prometheus-stack)
> **IMPORTANT**: For Packages using the helm or kube PackageSystem, these
> PackageComponents represent a Kubernetes Resource (Deployment, DaemonSet
> or StatefulSet) that is installed by the Package.
Simple examples of PackageComponents would be the Bitnami Cert-Manager Helm
Chart Package's controller Deployment, the webhook Deployment and the
cainjector Deployment.
More complex examples of PackageComponents might be the ArgoCD Official
Upstream Helm Chart Package's extensive collection of controllers, caches and
persistent database storage components installed in Deployment, Daemonset and
StatefulSet resources.
- [Update Package](https://docs.chkk.io/api-reference/v2/package/update-package.md): Update an existing Package
A Package is a named bundle of software that is bundled (and
identified) in the format of a specific PackageSystem.
A PackageSystem is an identifier of a packaging ecosystem.
Packages can use one of the following PackageSystems:
* helm for Helm charts
* kube for raw YAML manifests or Kustomize overlays that install one or
more Kubernetes resources
A Package is identified by a globally-unique ID field which is a UUID string
prefixed with the string 'pkg_', for example
'pkg_c42014e7-baf5-4ec6-a502-858f98dca7c8'.
A Package may be associated with one or more Projects and zero or more
ProjectComponents.
A Package may have one or more links associated with it. There are two types
of links that hold special significance to a package: 'package.archive' and
'package.source'. The 'package.archive' link is used to indicate the location
of the package's archive, which is the file that contains the package's
contents. The 'package.source' link is used to indicate a location on the web
where the package may be observed in an un-archived format. For example, the
cert-manager helm chart package can have the following links
- 'package.archive': https:charts.jetstack.io/cert-manager
- 'package.source': https:github.com/cert-manager/cert-manager/tree/master/deploy/charts/cert-manager
A Package may have zero or more aliases associated with it in the 'Aliases'
field. An alias for a Package is a human readable string that uniquely
identifies the Package.
A Package may be associated with one or more ProjectComponents. Packages with
PackageSystem helm or kube are associated with ProjectComponents
via the Package's collection of PackageComponents. A PackageComponent, which
corresponds to a specific Kubernetes Resource of Kind Deployment, DaemonSet or
StatefulSet, may reference one or more Docker Images. Those Docker Images
correspond to a ProjectComponent for one or more Projects.
- [Update Release](https://docs.chkk.io/api-reference/v2/package/update-release.md): Update an existing PackageRelease
A Package may have one or more PackageReleases. A PackageRelease is
the coordinated publication of one or more Packages for the Package having the
same Version string.
A PackageRelease is uniquely identified by the combination of the Package UUID
or Package Alias and a version string separated by an @ character.
Example PackageRelease identifiers:
* helm-chkk-operator@0.0.13: the Chkk Operator Helm Chart Package Alias of
helm-chkk-operator with a version string of 0.0.13
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a@1.24.12: the Package UUID of the
Cilium Helm Chart and the version string 1.24.12
* helm-kube-prometheus-stack@65.4.0: the Kube Prometheus Helm Chart Package
Alias of helm-kube-prometheus-stack with a version string of 65.4.0
A PackageRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the PackageRelease.
- [Update VersionSet](https://docs.chkk.io/api-reference/v2/package/update-versionset.md): Update an existing PackageVersionSet
A PackageVersionSet represents a configuration, layout or structure of
a Package that is consistent for a range of PackageReleases.
A PackageComponent is associated with a single PackageVersionSet. We track
changes to the componentry and structure of a Package over time using
PackageVersionSets.
PackageVersionSets are uniquely identified by the Package ID or Alias and
a simple integer, separated by a ':' character.
Examples of PackageVersionSet identifiers:
* argo-workflows:1: the first PackageVersionSet of the Argo Workflows
Package, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third PackageVersionSet of
the Argo Workflows Package, using the Argo Workflow Package's UUID as the
identifier.
Each PackageVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which PackageReleases the PackageVersionSet describes.
- [Create Component](https://docs.chkk.io/api-reference/v2/project/create-component.md): Create a new ProjectComponent
A ProjectComponent is a separate binary, daemon, or subsystem of a
Project.
> **NOTE**: ProjectComponents that are associated with a PackageComponent for a
> Package with PackageSystem kube or helm can be thought of as
> roughly equivalent to OCI/Docker Images, since the ProjectComponent
> describes a container within a Kubernetes Resource described by that
> PackageComponent.
A ProjectComponent is uniquely identified by the combination of a
ProjectVersionSet identifier and the Component name separated by a :
character. The Component name is a simple name indicating the binary, daemon
or subsystem.
Examples of ProjectComponent identifiers:
* argo-workflows:1:workflow-controller: the
workflow-controller binary of the first versionset of the Argo Workflows
Project, using the argo-workflows Alias as the Project identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3:workflow-controller: the
workflow-controller binary of the third ProjectVersionSet of the Argo
Workflows Project, using the Argo Workflow Project's UUID as the identifier.
- [Create Project](https://docs.chkk.io/api-reference/v2/project/create-project.md): Create a new Project
A Project is software that provides some functionality.
Projects are uniquely identified by a UUID, prefixed with the string
proj_, for example proj_c42014e7-baf5-4ec6-a502-858f98dca7c8
Projects can have zero or more Aliases. Aliases are completely free-form.
They can be a URL, like github.com/kubernetes/kubernetes or a short string
like k8s or kube.
Each Project has a ProjectType. Valid ProjectTypes include:
* platform: The Project represents a software platform, such as the
Kubernetes Project itself.
* kube-addon: The Project represents a Kubernetes Addon, which is defined as
some software that extends the functionality of the Kubernetes cluster and
its API.
* kube-operator: The Project represents a Kubernetes [Operator][operator],
which is defined as software written specifically against the Kubernetes API
and is responsible for installing and managing the lifecycle of a Kubernetes
Addon or Application Service.
* kube-control-plane-provider: The Project represents a Kubernetes control
plane service, such as RKE, GKE or EKS.
* application-service: The Project represents application code that provides
essential services to the rest of the application stack.
* application: The Project represents customer-specific or internal code.
A Project is not the packaging of that software. Packaging of
Projects is described by the Package model.
- [Create Release](https://docs.chkk.io/api-reference/v2/project/create-release.md): Create a new ProjectRelease
A Project may have one or more ProjectReleases. A ProjectRelease is
the coordinated publication of one or more Packages for the Project having the
same Version string.
A ProjectRelease is always associated with a single ProjectRelease.
A ProjectRelease is uniquely identified by the combination of the Project
identifier and the Version string, separated by an '@' character, e.g.
proj_a858f4d4-6e5b-4ab5-8d92-e9715b584ec1@1.5.12
A ProjectRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the ProjectRelease.
- [Create ReleaseSeries](https://docs.chkk.io/api-reference/v2/project/create-releaseseries.md): Create a new ProjectReleaseSeries
A Project may have one or more ProjectReleaseSeries. A
ProjectReleaseSeries describes a single release series for a Project.
ProjectReleaseSeries are identified by a simple string that must be unique
for the Project. Typically the ProjectReleaseSeries Name will be a major or
major.minor version series, e.g. "4" or "1.28", however this is not
universally true. Some Projects use date-based names like "2024.04".
A ProjectReleaseSeries has a PublishedOn date which indicates when the
release was originally "cut".
- [Create VersionSet](https://docs.chkk.io/api-reference/v2/project/create-versionset.md): Create a new ProjectVersionSet
A ProjectVersionSet represents a configuration, layout or structure of
a Project that is consistent for a range of ProjectReleases.
A ProjectComponent is associated with a single ProjectVersionSet. We track
changes to the componentry and structure of a Project over time using
ProjectVersionSets.
ProjectVersionSets are uniquely identified by the Project ID or Alias and
a simple integer, separated by a ':' character.
Examples of ProjectVersionSet identifiers:
* argo-workflows:1: the first ProjectVersionSet of the Argo Workflows
Project, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third ProjectVersionSet of
the Argo Workflows Project, using the Argo Workflow Project's UUID as the
identifier.
Each ProjectVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which ProjectReleases the ProjectVersionSet describes.
- [Delete Component](https://docs.chkk.io/api-reference/v2/project/delete-component.md): Delete a ProjectComponent
A ProjectComponent is a separate binary, daemon, or subsystem of a
Project.
> **NOTE**: ProjectComponents that are associated with a PackageComponent for a
> Package with PackageSystem kube or helm can be thought of as
> roughly equivalent to OCI/Docker Images, since the ProjectComponent
> describes a container within a Kubernetes Resource described by that
> PackageComponent.
A ProjectComponent is uniquely identified by the combination of a
ProjectVersionSet identifier and the Component name separated by a :
character. The Component name is a simple name indicating the binary, daemon
or subsystem.
Examples of ProjectComponent identifiers:
* argo-workflows:1:workflow-controller: the
workflow-controller binary of the first versionset of the Argo Workflows
Project, using the argo-workflows Alias as the Project identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3:workflow-controller: the
workflow-controller binary of the third ProjectVersionSet of the Argo
Workflows Project, using the Argo Workflow Project's UUID as the identifier.
- [Delete Project](https://docs.chkk.io/api-reference/v2/project/delete-project.md): Delete a Project
A Project is software that provides some functionality.
Projects are uniquely identified by a UUID, prefixed with the string
proj_, for example proj_c42014e7-baf5-4ec6-a502-858f98dca7c8
Projects can have zero or more Aliases. Aliases are completely free-form.
They can be a URL, like github.com/kubernetes/kubernetes or a short string
like k8s or kube.
Each Project has a ProjectType. Valid ProjectTypes include:
* platform: The Project represents a software platform, such as the
Kubernetes Project itself.
* kube-addon: The Project represents a Kubernetes Addon, which is defined as
some software that extends the functionality of the Kubernetes cluster and
its API.
* kube-operator: The Project represents a Kubernetes [Operator][operator],
which is defined as software written specifically against the Kubernetes API
and is responsible for installing and managing the lifecycle of a Kubernetes
Addon or Application Service.
* kube-control-plane-provider: The Project represents a Kubernetes control
plane service, such as RKE, GKE or EKS.
* application-service: The Project represents application code that provides
essential services to the rest of the application stack.
* application: The Project represents customer-specific or internal code.
A Project is not the packaging of that software. Packaging of
Projects is described by the Package model.
- [Delete Release](https://docs.chkk.io/api-reference/v2/project/delete-release.md): Delete a ProjectRelease
A Project may have one or more ProjectReleases. A ProjectRelease is
the coordinated publication of one or more Packages for the Project having the
same Version string.
A ProjectRelease is always associated with a single ProjectRelease.
A ProjectRelease is uniquely identified by the combination of the Project
identifier and the Version string, separated by an '@' character, e.g.
proj_a858f4d4-6e5b-4ab5-8d92-e9715b584ec1@1.5.12
A ProjectRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the ProjectRelease.
- [Delete ReleaseSeries](https://docs.chkk.io/api-reference/v2/project/delete-releaseseries.md): Delete a ProjectReleaseSeries
A Project may have one or more ProjectReleaseSeries. A
ProjectReleaseSeries describes a single release series for a Project.
ProjectReleaseSeries are identified by a simple string that must be unique
for the Project. Typically the ProjectReleaseSeries Name will be a major or
major.minor version series, e.g. "4" or "1.28", however this is not
universally true. Some Projects use date-based names like "2024.04".
A ProjectReleaseSeries has a PublishedOn date which indicates when the
release was originally "cut".
- [Delete VersionSet](https://docs.chkk.io/api-reference/v2/project/delete-versionset.md): Delete a ProjectVersionSet
A ProjectVersionSet represents a configuration, layout or structure of
a Project that is consistent for a range of ProjectReleases.
A ProjectComponent is associated with a single ProjectVersionSet. We track
changes to the componentry and structure of a Project over time using
ProjectVersionSets.
ProjectVersionSets are uniquely identified by the Project ID or Alias and
a simple integer, separated by a ':' character.
Examples of ProjectVersionSet identifiers:
* argo-workflows:1: the first ProjectVersionSet of the Argo Workflows
Project, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third ProjectVersionSet of
the Argo Workflows Project, using the Argo Workflow Project's UUID as the
identifier.
Each ProjectVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which ProjectReleases the ProjectVersionSet describes.
- [Get Component](https://docs.chkk.io/api-reference/v2/project/get-component.md): Gets a single ProjectComponent
A ProjectComponent is a separate binary, daemon, or subsystem of a
Project.
> **NOTE**: ProjectComponents that are associated with a PackageComponent for a
> Package with PackageSystem kube or helm can be thought of as
> roughly equivalent to OCI/Docker Images, since the ProjectComponent
> describes a container within a Kubernetes Resource described by that
> PackageComponent.
A ProjectComponent is uniquely identified by the combination of a
ProjectVersionSet identifier and the Component name separated by a :
character. The Component name is a simple name indicating the binary, daemon
or subsystem.
Examples of ProjectComponent identifiers:
* argo-workflows:1:workflow-controller: the
workflow-controller binary of the first versionset of the Argo Workflows
Project, using the argo-workflows Alias as the Project identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3:workflow-controller: the
workflow-controller binary of the third ProjectVersionSet of the Argo
Workflows Project, using the Argo Workflow Project's UUID as the identifier.
- [Get Project](https://docs.chkk.io/api-reference/v2/project/get-project.md): Gets a single Project
A Project is software that provides some functionality.
Projects are uniquely identified by a UUID, prefixed with the string
proj_, for example proj_c42014e7-baf5-4ec6-a502-858f98dca7c8
Projects can have zero or more Aliases. Aliases are completely free-form.
They can be a URL, like github.com/kubernetes/kubernetes or a short string
like k8s or kube.
Each Project has a ProjectType. Valid ProjectTypes include:
* platform: The Project represents a software platform, such as the
Kubernetes Project itself.
* kube-addon: The Project represents a Kubernetes Addon, which is defined as
some software that extends the functionality of the Kubernetes cluster and
its API.
* kube-operator: The Project represents a Kubernetes [Operator][operator],
which is defined as software written specifically against the Kubernetes API
and is responsible for installing and managing the lifecycle of a Kubernetes
Addon or Application Service.
* kube-control-plane-provider: The Project represents a Kubernetes control
plane service, such as RKE, GKE or EKS.
* application-service: The Project represents application code that provides
essential services to the rest of the application stack.
* application: The Project represents customer-specific or internal code.
A Project is not the packaging of that software. Packaging of
Projects is described by the Package model.
- [Get Release](https://docs.chkk.io/api-reference/v2/project/get-release.md): Gets a single ProjectRelease
A Project may have one or more ProjectReleases. A ProjectRelease is
the coordinated publication of one or more Packages for the Project having the
same Version string.
A ProjectRelease is always associated with a single ProjectRelease.
A ProjectRelease is uniquely identified by the combination of the Project
identifier and the Version string, separated by an '@' character, e.g.
proj_a858f4d4-6e5b-4ab5-8d92-e9715b584ec1@1.5.12
A ProjectRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the ProjectRelease.
- [Get ReleaseSeries](https://docs.chkk.io/api-reference/v2/project/get-releaseseries.md): Gets a single ProjectReleaseSeries
A Project may have one or more ProjectReleaseSeries. A
ProjectReleaseSeries describes a single release series for a Project.
ProjectReleaseSeries are identified by a simple string that must be unique
for the Project. Typically the ProjectReleaseSeries Name will be a major or
major.minor version series, e.g. "4" or "1.28", however this is not
universally true. Some Projects use date-based names like "2024.04".
A ProjectReleaseSeries has a PublishedOn date which indicates when the
release was originally "cut".
- [Get VersionSet](https://docs.chkk.io/api-reference/v2/project/get-versionset.md): Gets a single ProjectVersionSet
A ProjectVersionSet represents a configuration, layout or structure of
a Project that is consistent for a range of ProjectReleases.
A ProjectComponent is associated with a single ProjectVersionSet. We track
changes to the componentry and structure of a Project over time using
ProjectVersionSets.
ProjectVersionSets are uniquely identified by the Project ID or Alias and
a simple integer, separated by a ':' character.
Examples of ProjectVersionSet identifiers:
* argo-workflows:1: the first ProjectVersionSet of the Argo Workflows
Project, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third ProjectVersionSet of
the Argo Workflows Project, using the Argo Workflow Project's UUID as the
identifier.
Each ProjectVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which ProjectReleases the ProjectVersionSet describes.
- [List Components](https://docs.chkk.io/api-reference/v2/project/list-components.md): List multiple ProjectComponents
A ProjectComponent is a separate binary, daemon, or subsystem of a
Project.
> **NOTE**: ProjectComponents that are associated with a PackageComponent for a
> Package with PackageSystem kube or helm can be thought of as
> roughly equivalent to OCI/Docker Images, since the ProjectComponent
> describes a container within a Kubernetes Resource described by that
> PackageComponent.
A ProjectComponent is uniquely identified by the combination of a
ProjectVersionSet identifier and the Component name separated by a :
character. The Component name is a simple name indicating the binary, daemon
or subsystem.
Examples of ProjectComponent identifiers:
* argo-workflows:1:workflow-controller: the
workflow-controller binary of the first versionset of the Argo Workflows
Project, using the argo-workflows Alias as the Project identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3:workflow-controller: the
workflow-controller binary of the third ProjectVersionSet of the Argo
Workflows Project, using the Argo Workflow Project's UUID as the identifier.
- [List Projects](https://docs.chkk.io/api-reference/v2/project/list-projects.md): List multiple Projects
A Project is software that provides some functionality.
Projects are uniquely identified by a UUID, prefixed with the string
proj_, for example proj_c42014e7-baf5-4ec6-a502-858f98dca7c8
Projects can have zero or more Aliases. Aliases are completely free-form.
They can be a URL, like github.com/kubernetes/kubernetes or a short string
like k8s or kube.
Each Project has a ProjectType. Valid ProjectTypes include:
* platform: The Project represents a software platform, such as the
Kubernetes Project itself.
* kube-addon: The Project represents a Kubernetes Addon, which is defined as
some software that extends the functionality of the Kubernetes cluster and
its API.
* kube-operator: The Project represents a Kubernetes [Operator][operator],
which is defined as software written specifically against the Kubernetes API
and is responsible for installing and managing the lifecycle of a Kubernetes
Addon or Application Service.
* kube-control-plane-provider: The Project represents a Kubernetes control
plane service, such as RKE, GKE or EKS.
* application-service: The Project represents application code that provides
essential services to the rest of the application stack.
* application: The Project represents customer-specific or internal code.
A Project is not the packaging of that software. Packaging of
Projects is described by the Package model.
- [List Releases](https://docs.chkk.io/api-reference/v2/project/list-releases.md): List multiple ProjectReleases
A Project may have one or more ProjectReleases. A ProjectRelease is
the coordinated publication of one or more Packages for the Project having the
same Version string.
A ProjectRelease is always associated with a single ProjectRelease.
A ProjectRelease is uniquely identified by the combination of the Project
identifier and the Version string, separated by an '@' character, e.g.
proj_a858f4d4-6e5b-4ab5-8d92-e9715b584ec1@1.5.12
A ProjectRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the ProjectRelease.
- [List ReleaseSeries](https://docs.chkk.io/api-reference/v2/project/list-releaseseries.md): List multiple ProjectReleaseSeries
A Project may have one or more ProjectReleaseSeries. A
ProjectReleaseSeries describes a single release series for a Project.
ProjectReleaseSeries are identified by a simple string that must be unique
for the Project. Typically the ProjectReleaseSeries Name will be a major or
major.minor version series, e.g. "4" or "1.28", however this is not
universally true. Some Projects use date-based names like "2024.04".
A ProjectReleaseSeries has a PublishedOn date which indicates when the
release was originally "cut".
- [List VersionSets](https://docs.chkk.io/api-reference/v2/project/list-versionsets.md): List multiple ProjectVersionSets
A ProjectVersionSet represents a configuration, layout or structure of
a Project that is consistent for a range of ProjectReleases.
A ProjectComponent is associated with a single ProjectVersionSet. We track
changes to the componentry and structure of a Project over time using
ProjectVersionSets.
ProjectVersionSets are uniquely identified by the Project ID or Alias and
a simple integer, separated by a ':' character.
Examples of ProjectVersionSet identifiers:
* argo-workflows:1: the first ProjectVersionSet of the Argo Workflows
Project, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third ProjectVersionSet of
the Argo Workflows Project, using the Argo Workflow Project's UUID as the
identifier.
Each ProjectVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which ProjectReleases the ProjectVersionSet describes.
- [Update Component](https://docs.chkk.io/api-reference/v2/project/update-component.md): Update an existing ProjectComponent
A ProjectComponent is a separate binary, daemon, or subsystem of a
Project.
> **NOTE**: ProjectComponents that are associated with a PackageComponent for a
> Package with PackageSystem kube or helm can be thought of as
> roughly equivalent to OCI/Docker Images, since the ProjectComponent
> describes a container within a Kubernetes Resource described by that
> PackageComponent.
A ProjectComponent is uniquely identified by the combination of a
ProjectVersionSet identifier and the Component name separated by a :
character. The Component name is a simple name indicating the binary, daemon
or subsystem.
Examples of ProjectComponent identifiers:
* argo-workflows:1:workflow-controller: the
workflow-controller binary of the first versionset of the Argo Workflows
Project, using the argo-workflows Alias as the Project identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3:workflow-controller: the
workflow-controller binary of the third ProjectVersionSet of the Argo
Workflows Project, using the Argo Workflow Project's UUID as the identifier.
- [Update Project](https://docs.chkk.io/api-reference/v2/project/update-project.md): Update an existing Project
A Project is software that provides some functionality.
Projects are uniquely identified by a UUID, prefixed with the string
proj_, for example proj_c42014e7-baf5-4ec6-a502-858f98dca7c8
Projects can have zero or more Aliases. Aliases are completely free-form.
They can be a URL, like github.com/kubernetes/kubernetes or a short string
like k8s or kube.
Each Project has a ProjectType. Valid ProjectTypes include:
* platform: The Project represents a software platform, such as the
Kubernetes Project itself.
* kube-addon: The Project represents a Kubernetes Addon, which is defined as
some software that extends the functionality of the Kubernetes cluster and
its API.
* kube-operator: The Project represents a Kubernetes [Operator][operator],
which is defined as software written specifically against the Kubernetes API
and is responsible for installing and managing the lifecycle of a Kubernetes
Addon or Application Service.
* kube-control-plane-provider: The Project represents a Kubernetes control
plane service, such as RKE, GKE or EKS.
* application-service: The Project represents application code that provides
essential services to the rest of the application stack.
* application: The Project represents customer-specific or internal code.
A Project is not the packaging of that software. Packaging of
Projects is described by the Package model.
- [Update Release](https://docs.chkk.io/api-reference/v2/project/update-release.md): Update an existing ProjectRelease
A Project may have one or more ProjectReleases. A ProjectRelease is
the coordinated publication of one or more Packages for the Project having the
same Version string.
A ProjectRelease is always associated with a single ProjectRelease.
A ProjectRelease is uniquely identified by the combination of the Project
identifier and the Version string, separated by an '@' character, e.g.
proj_a858f4d4-6e5b-4ab5-8d92-e9715b584ec1@1.5.12
A ProjectRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the ProjectRelease.
- [Update ReleaseSeries](https://docs.chkk.io/api-reference/v2/project/update-releaseseries.md): Update an existing ProjectReleaseSeries
A Project may have one or more ProjectReleaseSeries. A
ProjectReleaseSeries describes a single release series for a Project.
ProjectReleaseSeries are identified by a simple string that must be unique
for the Project. Typically the ProjectReleaseSeries Name will be a major or
major.minor version series, e.g. "4" or "1.28", however this is not
universally true. Some Projects use date-based names like "2024.04".
A ProjectReleaseSeries has a PublishedOn date which indicates when the
release was originally "cut".
- [Update VersionSet](https://docs.chkk.io/api-reference/v2/project/update-versionset.md): Update an existing ProjectVersionSet
A ProjectVersionSet represents a configuration, layout or structure of
a Project that is consistent for a range of ProjectReleases.
A ProjectComponent is associated with a single ProjectVersionSet. We track
changes to the componentry and structure of a Project over time using
ProjectVersionSets.
ProjectVersionSets are uniquely identified by the Project ID or Alias and
a simple integer, separated by a ':' character.
Examples of ProjectVersionSet identifiers:
* argo-workflows:1: the first ProjectVersionSet of the Argo Workflows
Project, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third ProjectVersionSet of
the Argo Workflows Project, using the Argo Workflow Project's UUID as the
identifier.
Each ProjectVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which ProjectReleases the ProjectVersionSet describes.
- [Chkk + EKS Auto Mode](https://docs.chkk.io/chkk-eks-automode.md): Do EKS Auto Mode clusters need Chkk Upgrade Copilot?
- [Chkk + EKS Upgrade Insights](https://docs.chkk.io/chkk-eks-upgrade-insights.md): How Chkk Upgrade Copilot uses Amazon EKS Upgrade Insights
- [Chkk Cloud Connector](https://docs.chkk.io/connectors/chkk-cloud-connector.md): An overview of the Chkk Cloud Connector
- [Chkk Kubernetes Connector](https://docs.chkk.io/connectors/chkk-kubernetes-connector.md): An overview of Chkk Kubernetes Connector — what it is, why you need it, and how to install and configure it.
- [Activity Feed](https://docs.chkk.io/features/activity-feed.md): A brief description, use-case, and usage instructions of the Activity Feed feature
- [Comments](https://docs.chkk.io/features/add-comments.md): A brief description, use-case, and usage instructions of the Add Comments feature
- [Custom Steps](https://docs.chkk.io/features/add-edit-delete-custom-steps.md): A brief description, use-case, and usage instructions of the Add/Edit/Delete Custom Steps feature
- [Add-on Upgrade Recommendation](https://docs.chkk.io/features/addon-upgrade-recommendation.md): A brief description and use-case of the Add-on Upgrade Recommendation feature
- [Approve Upgrade Template](https://docs.chkk.io/features/approve-upgrade-template.md): A brief description, use-case, and usage instructions for the Approve Upgrade Template feature
- [Cancel an Upgrade Template or Plan](https://docs.chkk.io/features/cancel-upgrade-template-plan.md): A brief description, use-case, and usage instructions of the Cancel Upgrade Template/Plan feature
- [Captured Learnings](https://docs.chkk.io/features/captured-learnings.md): A brief description and use-case of the Captured Learnings feature
- [Environment Upgraded](https://docs.chkk.io/features/environment-upgraded.md): A brief description, use-case, and usage instructions of the Environment Upgraded feature
- [Feedback Button](https://docs.chkk.io/features/feedback-button.md): A brief description, use-case, and usage instructions of the Feedback Button feature
- [Upgrade Plan Instantiation](https://docs.chkk.io/features/instantiate-template-to-plan.md): A brief description, use-case, and usage instructions of the Upgrade Plan Instantiation feature
- [Upgrade Plan Marked as Completed](https://docs.chkk.io/features/mark-upgrade-plan-completed.md): A brief description, use-case, and usage instructions of the Upgrade Plan Marked as Completed feature
- [Readiness Checks](https://docs.chkk.io/features/readiness-checks.md): A brief description, use-case, and usage instructions of the Readiness Checks feature
- [Template Regeneration](https://docs.chkk.io/features/regenerate-template.md): A brief description, use-case, and usage instructions of the Template Regeneration feature
- [Release Notes Curation](https://docs.chkk.io/features/release-notes-curation.md): A brief description, use-case, and usage instructions of the Release Notes Curation feature
- [Upgrade Template Request](https://docs.chkk.io/features/request-upgrade-template.md): A brief description, use-case, and usage instructions of the Upgrade Template Request feature
- [Upgrade Guidance](https://docs.chkk.io/features/upgrade-guidance.md): A brief description, use-case, and usage instructions of the Upgrade Guidance feature
- [Upgrade Preverification](https://docs.chkk.io/features/upgrade-preverification.md): A brief description, use-case, and usage instructions of the Upgrade Preverification feature
- [Upgrade Template/Plan Ownership](https://docs.chkk.io/features/upgrade-template-plan-ownership.md): A brief description, use-case, and usage instructions of the Upgrade Template/Plan Ownership feature
- [Glossary of Terms](https://docs.chkk.io/misc/glossary.md): Definitions of key Chkk terms to help you navigate our platform and docs
- [Troubleshooting](https://docs.chkk.io/misc/troubleshooting.md): Troubleshooting
- [IaC Repo Patterns](https://docs.chkk.io/operations/iac-repo-patterns.md): Taxonomy of Helm, Kustomize, Terraform, Pulumi, and GitOps Patterns
- [Getting Started](https://docs.chkk.io/overview/getting-started.md): This Quick Start Guide provides a streamlined, step-by-step process for onboarding to Chkk, ensuring users can quickly start leveraging its risk detection, artifact tracking, and upgrade planning capabilities.
- [Welcome to Chkk](https://docs.chkk.io/overview/introduction.md): Agentic Upgrades for Open Source Software. Built for Kubernetes, Add-ons, Application Services and 100s of Open Source Software Projects
- [Support and Compatibility](https://docs.chkk.io/overview/support-compatibility.md): An overview of the cloud providers, Kubernetes distributions, Kubernetes Add-ons, Application Services, and Operators that Chkk supports
- [Technology](https://docs.chkk.io/overview/technology.md)
- [Understanding Chkk](https://docs.chkk.io/overview/understanding-chkk.md)
- [Overview](https://docs.chkk.io/product/artifact-register/overview.md): Inventory of everything in a Kubernetes fleet
- [Chkk Operational Safety Platform](https://docs.chkk.io/product/introduction.md): Chkk Operational Safety Platform
- [Marketplaces](https://docs.chkk.io/product/marketplaces.md): Purchase Chkk from AWS Marketplace and GCP Marketplace
- [Subscription Plans](https://docs.chkk.io/product/pricing-plans.md): Business and Enterprise Plans
- [Overview](https://docs.chkk.io/product/risk-ledger/overview.md): Eliminate risks before they cause incidents
- [Upgrade Assessments](https://docs.chkk.io/product/upgrade-copilot/assessments.md): Foundational reports that map scope, risk, and dependencies of OSS project and Kubernetes upgrades.
- [Overview](https://docs.chkk.io/product/upgrade-copilot/overview.md): Your Upgrade Copilot for 100s of OSS Projects, Kubernetes, and Add-ons.
- [Upgrade Plans](https://docs.chkk.io/product/upgrade-copilot/plans.md): Cluster-specific or OSS project-specific upgrade workflows instantiated from approved Templates.
- [Upgrade Plans vs Templates](https://docs.chkk.io/product/upgrade-copilot/plans-vs-templates.md): Understand the difference and relationship between Templates and Plans.
- [Upgrade Templates](https://docs.chkk.io/product/upgrade-copilot/templates.md): Reusable, AI-curated upgrade workflows for 100s of OSS projects, Kubernetes, and add-ons.
- [Amazon VPC CNI](https://docs.chkk.io/projects/addons/amazon-vpc-cni.md): Chkk coverage for Amazon VPC CNI. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
- [Calico](https://docs.chkk.io/projects/addons/calico.md): Chkk coverage for Calico. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [cert-manager](https://docs.chkk.io/projects/addons/cert-manager.md): Chkk coverage for cert-manager. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
- [Cilium](https://docs.chkk.io/projects/addons/cilium.md): Chkk coverage for Cilium. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
- [Cluster Autoscaler](https://docs.chkk.io/projects/addons/cluster-autoscaler.md): Chkk coverage for Cluster Autoscaler. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Contour](https://docs.chkk.io/projects/addons/contour.md): Chkk coverage for Contour. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [CoreDNS](https://docs.chkk.io/projects/addons/coredns.md): Chkk coverage for CoreDNS. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [External DNS](https://docs.chkk.io/projects/addons/external-dns.md): Chkk coverage for External DNS. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
- [External Secrets Operator](https://docs.chkk.io/projects/addons/external-secrets-operator.md): Chkk coverage for External Secrets Operator. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
- [Gloo Edge OSS](https://docs.chkk.io/projects/addons/gloo-edge-oss.md): Chkk coverage for Gloo Edge OSS. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
- [Ingress NGINX Controller](https://docs.chkk.io/projects/addons/ingress-nginx-controller.md): Chkk coverage for Ingress NGINX Controller. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
- [Istio](https://docs.chkk.io/projects/addons/istio.md): Chkk coverage for Istio. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [kube-proxy](https://docs.chkk.io/projects/addons/kube-proxy.md): Chkk coverage for kube-proxy. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
- [kube-state-metrics](https://docs.chkk.io/projects/addons/kube-state-metrics.md): Chkk coverage for kube-state-metrics. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
- [Kubernetes Dashboard](https://docs.chkk.io/projects/addons/kubernetes-dashboard.md): Chkk coverage for Kubernetes Dashboard. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Kubernetes Metrics Server](https://docs.chkk.io/projects/addons/kubernetes-metrics-server.md): Chkk coverage for Kubernetes Metrics Server. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
- [Add-ons](https://docs.chkk.io/projects/addons/overview.md): Explore All the Kubernetes Add-ons Chkk Covers
- [Vertical Pod Autoscaler](https://docs.chkk.io/projects/addons/vertical-pod-autoscaler.md): Chkk coverage for Vertical Pod Autoscaler. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
- [Alertmanager](https://docs.chkk.io/projects/application-services/alertmanager.md): Chkk coverage for Alertmanager. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Apache Kafka](https://docs.chkk.io/projects/application-services/apache-kafka.md): Chkk coverage for Apache Kafka. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
- [Apache Zookeeper](https://docs.chkk.io/projects/application-services/apache-zookeeper.md): Chkk coverage for Apache Zookeeper. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
- [Argo CD](https://docs.chkk.io/projects/application-services/argo-cd.md): Chkk coverage for Argo CD. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Argo Rollouts](https://docs.chkk.io/projects/application-services/argo-rollouts.md): Chkk coverage for Argo Rollouts. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
- [Argo Workflows](https://docs.chkk.io/projects/application-services/argo-workflows.md): Chkk coverage for Argo Workflows. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Crossplane](https://docs.chkk.io/projects/application-services/crossplane.md): Chkk coverage for Crossplane. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
- [Datadog Agent](https://docs.chkk.io/projects/application-services/datadog-agent.md): Chkk coverage for Datadog Agent. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
- [Elasticsearch](https://docs.chkk.io/projects/application-services/elasticsearch.md): Chkk coverage for Elasticsearch. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
- [Fluent Bit](https://docs.chkk.io/projects/application-services/fluent-bit.md): Chkk coverage for Fluent Bit. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
- [Grafana](https://docs.chkk.io/projects/application-services/grafana.md): Chkk coverage for Grafana. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
- [Grafana Loki](https://docs.chkk.io/projects/application-services/grafana-loki.md): Chkk coverage for Grafana Loki. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [HashiCorp Consul OSS](https://docs.chkk.io/projects/application-services/hashicorp-consul-oss.md): Chkk coverage for HashiCorp Consul OSS. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
- [HashiCorp Vault](https://docs.chkk.io/projects/application-services/hashicorp-vault.md): Chkk coverage for HashiCorp Vault. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Karpenter](https://docs.chkk.io/projects/application-services/karpenter.md): Chkk coverage for Karpenter. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
- [KEDA](https://docs.chkk.io/projects/application-services/keda.md): Chkk coverage for KEDA. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
- [Keycloak](https://docs.chkk.io/projects/application-services/keycloak.md): Chkk coverage for Keycloak. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
- [Kyverno](https://docs.chkk.io/projects/application-services/kyverno.md): Chkk coverage for Kyverno. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
- [Application Services](https://docs.chkk.io/projects/application-services/overview.md): Explore All the Application Services Chkk Covers
- [Prometheus](https://docs.chkk.io/projects/application-services/prometheus.md): Chkk coverage for Prometheus. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
- [RabbitMQ](https://docs.chkk.io/projects/application-services/rabbitmq.md): Chkk coverage for RabbitMQ. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
- [Redis](https://docs.chkk.io/projects/application-services/redis.md): Chkk coverage for Redis. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Bottlerocket Update Operator](https://docs.chkk.io/projects/kubernetes-operators/bottlerocket-update-operator.md): Chkk coverage for Bottlerocket Update Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Calico Operator](https://docs.chkk.io/projects/kubernetes-operators/calico-operator.md): Chkk coverage for Calico Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Cilium Operator](https://docs.chkk.io/projects/kubernetes-operators/cilium-operator.md): Chkk coverage for Cilium Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Clickhouse Operator](https://docs.chkk.io/projects/kubernetes-operators/clickhouse-operator.md): Chkk coverage for Clickhouse Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Datadog Operator](https://docs.chkk.io/projects/kubernetes-operators/datadog-operator.md): Chkk coverage for Datadog Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Dynatrace Operator](https://docs.chkk.io/projects/kubernetes-operators/dynatrace-operator.md): Chkk coverage for Dynatrace Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Elasticsearch (ECK) Operator](https://docs.chkk.io/projects/kubernetes-operators/eck-operator.md): Chkk coverage for Elasticsearch (ECK) Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Keycloak Operator](https://docs.chkk.io/projects/kubernetes-operators/keycloak-operator.md): Chkk coverage for Keycloak Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Kiali Operator](https://docs.chkk.io/projects/kubernetes-operators/kiali-operator.md): Chkk coverage for Kiali Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [MinIO Operator](https://docs.chkk.io/projects/kubernetes-operators/minio-operator.md): Chkk coverage for MinIO Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Operators](https://docs.chkk.io/projects/kubernetes-operators/overview.md): Explore All the Kubernetes Operators Chkk Covers
- [Vault Secrets Operator](https://docs.chkk.io/projects/kubernetes-operators/vault-secrets-operator.md): Chkk coverage for Vault Secrets Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
- [Overview](https://docs.chkk.io/projects/overview.md)
- [Secure Architecture](https://docs.chkk.io/security/architecture.md)
- [Compliance](https://docs.chkk.io/security/compliance.md)
- [Security-First Culture](https://docs.chkk.io/security/culture.md)
- [Data Protection & Handling](https://docs.chkk.io/security/data-handling.md)
- [Privacy Policy](https://docs.chkk.io/security/privacy-policy.md)
- [Subprocessors and Third-Party Security](https://docs.chkk.io/security/subprocessors.md)
- [Terms of Service](https://docs.chkk.io/security/tos.md)
- [Trust Center and Transparency](https://docs.chkk.io/security/trust-center.md)
- [Avoid 6x Extended Support Fees](https://docs.chkk.io/usecases/avoid-extended-support-fees.md)
- [Delegate, Parallelize, and Standardize Workflows](https://docs.chkk.io/usecases/delegate-parallelize-standardize-workflows.md)
- [Enhance Operational Safety](https://docs.chkk.io/usecases/enhance-operational-safety.md)
- [Improve Resource Efficiency](https://docs.chkk.io/usecases/improve-resource-efficiency.md)
- [Speedup and Derisk Upgrades](https://docs.chkk.io/usecases/speed-derisk-upgrades.md)
## Optional
- [Blog](https://chkk.io/blog)