f7c9499e7d
* initial commit with atomist content * updated domain name for dso * updated tutorial * fixed broken link * updated image policies * rm excess pages * update toc and remove broken links * first pass on k8s integration pageg * updated dockerfile label * reworked policies, restructuring * update links, rm dockerhub integration * added reference to seamless docker hub integration * added back hub tab in get started * fix platform statement for connect registry * update get-started * update try instruction * edited deploy tracking * rm policies from toc, update advisories page * moved advisories page to new reference section * removed unsupported settings * removed gitops and k8s adm ctrl * shift emphasis from scanning to sboms * fix typo in oci label Co-authored-by: CrazyMax <github@crazymax.dev> * address review comments * added buildx and other edits * updated try tutorial * update google instructions * removed unsupported content * add disclaimer to settings page * editorial, cleanup * minor updates * fix toc * address review comments * fix broken link Signed-off-by: David Karlsson <david.karlsson@docker.com> Signed-off-by: David Karlsson <david.karlsson@docker.com> Co-authored-by: CrazyMax <github@crazymax.dev>
3.1 KiB
title, description, keywords
| title | description | keywords |
|---|---|---|
| Track deployments | Deployment tracking lets Atomist compare your image builds with what's running in your environments. | deployment, kubernetes, security |
{% include atomist/disclaimer.md %}
By integrating Atomist with a runtime environment, you can track vulnerabilities for deployed containers. This gives you contexts for whether security debt is increasing or decreasing.
There are several options for how you could implement deployment tracking:
- Invoking the API directly
- Adding it as a step in your continuous deployment pipeline
- Creating Kubernetes admission controllers
API
Each Atomist workspace exposes an API endpoint. Submitting a POST request to the endpoint updates Atomist about what image you are running in your environments. This lets you compare data for images you build against images of containers running in staging or production.
You can find the API endpoint URL on the Integrations page. Using this API requires an API key.
The most straight-forward use is to post to this endpoint using a webhook. When
deploying a new image, submit an automated POST request (using curl, for
example) as part of your deployment pipeline.
$ curl <api-endpoint-url> \\
-X POST \\
-H "Content-Type: application/json" \\
-H "Authorization: Bearer <api-token>" \\
-d '{"image": {"url": "<image-url>@<sha256-digest>"}}'
Parameters
The API supports the following parameters in the request body:
{
"image": {
"url": "string",
"name": "string"
},
"environment": {
"name": "string"
},
"platform": {
"os": "string",
"architecture": "string",
"variant": "string"
}
}
| Parameter | Mandatory | Default | Description |
|---|---|---|---|
image.url |
Yes | Fully qualified reference name of the image, plus version (digest). You must specify the image version by digest. | |
image.name |
No | Optional identifier. If you deploy many containers from the same image in any one environment, each instance must have a unique name. | |
environment.name |
No | deployed |
Use custom environment names to track different image versions in environments, like staging and production |
platform.os |
No | linux |
Image operating system. |
platform.architecture |
No | amd64 |
Instruction set architecture. |
platform.variant |
No | Optional variant label. |