I want to create policy that will check that image digest (sha) is part of white list and will approve it.
My problem is that the deployment done via image name and image tag and I try to find a way to convert the tag to sha on the fly.
Does OPA can do get sha of image?
A Docker image's digest is the SHA256 of its config.json file. Without this (i.e. from only the repository and tag) you can't create the digest, with OPA or any other tool. If you do have the config.json file at hand you can create the digest using it as input to the crypto.sha256(string) built-in, but you are probably better off retrieving the digest directly from either the Docker API or you registry, depending on your use case.
Related
I thought that tags in Docker worked like in stackoverflow where millions of questions can be tagged with the same tag. But when I tag a second image in Docker the first one loses its tag:
So are images to tags one-to-many, i.e. one image can have multiple tags in a repo, but a tag cannot be applied to 2 or more images in the same repo?
Pushing a new tag replaces the old tag, but if you know the digest, you can pull the old manifest until the registry garbage collects it.
A tag is a pointer to a manifest in the registry, and it can only point to a single manifest, similar to a symlink in Linux. This is needed since everything else in the registry is content addressable, so you need the tag to avoid needing to remember long digests.
There are a couple manifest types, an image manifest, and a manifest list. The manifest list contains references to other manifests, which is commonly used for multi-platform images. So a tag pointing to a manifest list could refer to multiple images using a manifest list. But runtimes will only pull a single image out of that list. And that list is generated by the tool pushing the image, not dynamically created by the registry by merging the previous images into a list (that would break the content addressable logic since it would change the digest).
I am facing an issue when I try to create a custom image containing tensorflow. But when I use the official repositories I did not see that problem. Then I am trying to know which Docker file from https://github.com/tensorflow/tensorflow/tree/master/tensorflow/tools/dockerfiles/dockerfiles was used to generate the Docker.hub image. Could you help me, please?
You can always use [docker image inspect][1] to get further information about an image's layers and how it was built locally.
On docker hub if you click on the tags tab, you can click on any image, and it will show you that info in a very nice annotation of that image's layers. Next to the dockerfile.
I have VM in compute Engine running a docker image uploaded to the Container Registry.
If i push a new image with the same name, is "Reset" enough to load that image or should I keep doing stop+Start?
When you upload a docker image to the Container Registry, apart from the name, it would be wise to tag it. If you upload another image with the same name, and same tag, it is enough using reset for the VM to use the new image. Upon resetting, you will be using the image with the same name and tag of the image you first used to deploy a VM. If you do not use tags, the new images you push with the same name without tag will be automatically tagged as "latest", and that one will be used after doing "reset" to your VM.
When using tags, upon uploading the new image with same name and tag, the previous image will lose the tag and the newly uploaded will get it.
I am trying to understand the connection between the image ID as reported by docker images (or docker inspect) and the actual layers or images in the registry or manifest (using v2).
I run docker images, I get (abbreviated and changed to protect the not-so-innocent):
REPOSITORY TAG IMAGE ID
my.local.registry/some/image latest abcdefg
If I pull the manifest for the above image using the API, I get one that contains fsLayers, not one of which matches the (full) ID for the image. I get that, since the image is the sum of the layers.
However, if I pull that image elsewhere, I get the same ID. If I update the image, push and pull it, the new version has a new ID.
I thought it might be the hash of the manifest. However, (a) pulling the manifest via the API does not return the hash of the manifest in the JSON, and (b) looking in the registry directory itself, the sha256 of the given manifest in /var/lib/registry/v2/repositories/some/image/_manifests/tags/latest/current/link (or those in index/sha256/) give the correct link for the manifest that was downloaded, but does not match the image ID.
I had assumed the image ID matches the blob, but perhaps I am in error?
When we push an image into a registry,
We create a manifest that defines the image - layers inside it, and push both the manifest and layers independently.
We compress the layers and only then push them.
So in our host the hashes we have are the hashes of the content present in those layers, called the Content Hashes.
But to the registry we send the compressed layers, due to which the content changes and so the hashes change. So before those compressed layers are sent, the hashes for the compressed layers are calculated which are called the Distribution Hashes and those hashes are put in the manifest file.
Due to the difference in these Content and Distribution hashes, you see a difference in the ids.
I'm using the Docker Remote API (API v1.6, Docker 0.6.5). I'm building an image via the POST /build endpoint. FWIW, my client is written in Go. Is there a way to get the image ID of the image I just created without having to parse it out of the streamed response text?
You could give it a name (e.g. repo:tag) during the build and then inspect information about the tagged image using GET /images/(tag name)/json. (docs)
The json information includes the id, as well as the "config" which shows how the image was created in the first place.