A tartalmak megbízhatósága az Azure Container RegistrybenContent trust in Azure Container Registry

Azure Container Registry a Docker tartalmi megbízhatósági modelljét valósítja meg, amely lehetővé teszi az aláírt lemezképek leküldését és húzását.Azure Container Registry implements Docker's content trust model, enabling pushing and pulling of signed images. Ebből a cikkből megtudhatja, hogyan engedélyezheti a tartalom megbízhatóságát a tároló-beállításjegyzékben.This article gets you started enabling content trust in your container registries.

Megjegyzés

A tartalom megbízhatósága Azure Container Registry prémium SKU -jának egyik funkciója.Content trust is a feature of the Premium SKU of Azure Container Registry.

A tartalommegbízhatóság működéseHow content trust works

A biztonsági szempontok mentén kialakított elosztott rendszerek esetében rendkívül fontos a rendszerbe belépő adatok forrásának és integritásának ellenőrzése.Important to any distributed system designed with security in mind is verifying both the source and the integrity of data entering the system. Elengedhetetlen, hogy az adatok felhasználói képesek legyenek ellenőrizni az adatok közzétevőjét (forrás), valamint azt is, hogy az adatok a közzétételük után nem lettek-e módosítva (integritás).Consumers of the data need to be able to verify both the publisher (source) of the data, as well as ensure it's not been modified after it was published (integrity).

A rendszerképek közzétevőjeként a tartalommegbízhatóság alkalmazásával aláírhatja a regisztrációs adatbázisba leküldött rendszerképeket.As an image publisher, content trust allows you to sign the images you push to your registry. A rendszerképek felhasználói (az azokat a regisztrációs adatbázisból lehívó személyek vagy rendszerek) konfigurálhatják az ügyfeleket, hogy azok csak aláírt rendszerképeket kérjenek le.Consumers of your images (people or systems pulling images from your registry) can configure their clients to pull only signed images. Amikor valamely rendszerkép-felhasználó lekér egy aláírt rendszerképet, a Docker-ügyfél ellenőrzi a rendszerkép integritását.When an image consumer pulls a signed image, their Docker client verifies the integrity of the image. Ebben a modellben a felhasználók biztosak lehetnek benne, hogy az adatbázisban található aláírt rendszerképeket valóban Ön tette közzé, és azok a közzétételüket követően nem lettek módosítva.In this model, consumers are assured that the signed images in your registry were indeed published by you, and that they've not been modified since being published.

Megbízható rendszerképekTrusted images

A tartalommegbízhatóság az adattárak címkéivel is használható.Content trust works with the tags in a repository. A rendszerkép-adattárak aláírt és nem aláírt címkékkel rendelkező rendszerképeket egyaránt tartalmazhatnak.Image repositories can contain images with both signed and unsigned tags. Tegyük fel például, hogy csak a myimage:stable és a myimage:latest rendszerképet szeretné aláírni, a myimage:dev rendszerképet viszont nem.For example, you might sign only the myimage:stable and myimage:latest images, but not myimage:dev.

AláírókulcsokSigning keys

A tartalommegbízhatóság titkosítási aláírókulcsok használatával valósul meg.Content trust is managed through the use of a set of cryptographic signing keys. A kulcsok egy adott adattárral vannak társítva az adatbázisban.These keys are associated with a specific repository in a registry. A Docker-ügyfelek és az adatbázis által az adattárban lévő címkék megbízhatóságának kezeléséhez használt aláírókulcsoknak több típusa létezik.There are several types of signing keys that Docker clients and your registry use in managing trust for the tags in a repository. A tartalommegbízhatóság engedélyezése és a közzétételi és fogyasztási folyamatokba való integrálása esetén ezeket a kulcsokat gondosan kell felügyelnie.When you enable content trust and integrate it into your container publishing and consumption pipeline, you must manage these keys carefully. További információért lásd a cikk későbbi, a Kulcskezelő dokumentációjában található, a tartalom megbízhatóságára vonatkozó kulcsok kezelése című témakörét.For more information, see Key management later in this article and Manage keys for content trust in the Docker documentation.

Tipp

Ez a Docker tartalommegbízhatósági modelljének összefoglaló jellegű áttekintése volt.This was a very high-level overview of Docker's content trust model. A tartalom megbízhatóságának részletes megvitatására a tartalom megbízhatósága a Docker-bencímű témakörben talál további információt.For an in-depth discussion of content trust, see Content trust in Docker.

Tárolóregisztrációs adatbázis tartalommegbízhatóságának engedélyezéseEnable registry content trust

Első lépésként az adatbázis szintjén kell engedélyezni a tartalommegbízhatóságot.Your first step is to enable content trust at the registry level. Miután engedélyezte a tartalommegbízhatóságot, az ügyfelek (felhasználók és szolgáltatások) aláírt rendszerképeket a küldhetnek az adatbázisba.Once you enable content trust, clients (users or services) can push signed images to your registry. Ha a tartalommegbízhatóság engedélyezve van az adatbázisban, az nem korlátozza az adatbázis használatát azokra a felhasználókra, akiknél az szintén engedélyezve van.Enabling content trust on your registry does not restrict registry usage only to consumers with content trust enabled. Azok a felhasználók, akiknél nincs engedélyezve, továbbra is a szokott módon használhatják az adatbázist.Consumers without content trust enabled can continue to use your registry as normal. Azok a felhasználók azonban, akik engedélyezték a tartalommegbízhatóságot az ügyfeleiken, kizárólag az aláírt rendszerképeket látják majd az adatbázisban.Consumers who have enabled content trust in their clients, however, will be able to see only signed images in your registry.

A tartalommegbízhatóság az adatbázisban való engedélyezéséhez először lépjen az adatbázishoz az Azure Portalon.To enable content trust for your registry, first navigate to the registry in the Azure portal. A házirendekterületen válassza a tartalom megbízhatósága > engedélyezve > Mentéslehetőséget.Under Policies, select Content Trust > Enabled > Save. Az Azure CLI-ben az az ACR config Content-Trust Update parancsot is használhatja.You can also use the az acr config content-trust update command in the Azure CLI.

Tartalommegbízhatóság engedélyezése egy adatbázishoz az Azure Portalon

A tartalommegbízhatóság engedélyezése az ügyfelekenEnable client content trust

A megbízható rendszerképek használatához a rendszerképek közzétevőinek és felhasználóinak is engedélyezniük kell a tartalommegbízhatóságot a saját Docker-ügyfeleiken.To work with trusted images, both image publishers and consumers need to enable content trust for their Docker clients. A közzétevők aláírhatják az olyan adatbázisokba leküldött rendszerképeket, amelyeken a tartalommegbízhatóság engedélyezve van.As a publisher, you can sign the images you push to a content trust-enabled registry. A felhasználók a tartalommegbízhatóság engedélyezésével kizárólag az aláírt rendszerképeket láthatják az adatbázisban.As a consumer, enabling content trust limits your view of a registry to signed images only. A tartalommegbízhatóság alapértelmezés szerint le van tiltva a Docker-ügyfeleken, azonban felületi munkamenetenként vagy parancsonként engedélyezhető.Content trust is disabled by default in Docker clients, but you can enable it per shell session or per command.

A tartalommegbízhatóság egy adott felületi munkamenethez való engedélyezéséhez állítsa a DOCKER_CONTENT_TRUST környezeti változót 1 értékűre.To enable content trust for a shell session, set the DOCKER_CONTENT_TRUST environment variable to 1. Például a Bash-felületen:For example, in the Bash shell:

# Enable content trust for shell session
export DOCKER_CONTENT_TRUST=1

Ha inkább csak egyetlen parancshoz szeretné engedélyezni vagy letiltani a tartalommegbízhatóságot, több Docker-parancs is támogatja a --disable-content-trust argumentumot.If instead you'd like to enable or disable content trust for a single command, several Docker commands support the --disable-content-trust argument. A tartalommegbízhatóság engedélyezése egyetlen parancsra:To enable content trust for a single command:

# Enable content trust for single command
docker build --disable-content-trust=false -t myacr.azurecr.io/myimage:v1 .

Ha engedélyezte a tartalommegbízhatóságot a felületi munkamenethez, és le szeretné tiltani egyetlen parancs esetében:If you've enabled content trust for your shell session and want to disable it for a single command:

# Disable content trust for single command
docker build --disable-content-trust -t myacr.azurecr.io/myimage:v1 .

Rendszerkép-aláírási engedélyek kiosztásaGrant image signing permissions

Csak azok a felhasználók és rendszerek küldhetnek le megbízható rendszerképeket az adatbázisba, amelyeknek engedélyezte ezt.Only the users or systems you've granted permission can push trusted images to your registry. Ha egy felhasználónak (vagy egy szolgáltatásnevet használó rendszernek) engedélyezni szeretné a megbízható rendszerképek leküldését, ossza ki a felhasználó Azure Active Directory-identitásának az AcrImageSigner szerepkört.To grant trusted image push permission to a user (or a system using a service principal), grant their Azure Active Directory identities the AcrImageSigner role. Ez a lemezképek beállításjegyzékbe való küldéséhez szükséges AcrPush (vagy ezzel egyenértékű) szerepkörön kívül van.This is in addition to the AcrPush (or equivalent) role required for pushing images to the registry. Részletekért lásd: Azure Container Registry szerepkörök és engedélyek.For details, see Azure Container Registry roles and permissions.

Megjegyzés

Nem adhat megbízható leküldéses engedélyt az Azure Container Registry rendszergazdai fiókjához .You can't grant trusted image push permission to the admin account of an Azure container registry.

Az alábbiakban ismertetjük az AcrImageSigner szerepkör az Azure Portalon és az Azure CLI felületen való kiosztásának részleteit.Details for granting the AcrImageSigner role in the Azure portal and the Azure CLI follow.

Azure PortalAzure portal

Keresse meg a beállításjegyzéket a Azure Portalban, majd válassza a hozzáférés-vezérlés (iam) lehetőséget > szerepkör-hozzárendelés hozzáadásaelemet.Navigate to your registry in the Azure portal, then select Access control (IAM) > Add role assignment. A szerepkör-hozzárendelés hozzáadásaterületen válassza ki AcrImageSigner elemet a szerepkörterületen, majd válasszon ki egy vagy több felhasználót vagy szolgáltatásnevet, majd mentse.Under Add role assignment, select AcrImageSigner under Role, then Select one or more users or service principals, then Save.

Ebben a példában két entitásnak osztottuk ki az AcrImageSigner szerepkört: egy „service-principal” nevű szolgáltatásnévnek és egy „Azure User” nevű felhasználónak.In this example, two entities have been assigned the AcrImageSigner role: a service principal named "service-principal," and a user named "Azure User."

Tartalommegbízhatóság engedélyezése egy adatbázishoz az Azure Portalon

Azure CLIAzure CLI

Ha az Azure CLI használatával szeretne aláírási engedélyeket kiosztani egy felhasználónak, rendelje hozzá az AcrImageSigner szerepkört az adatbázisra vonatkozó hatókörrel.To grant signing permissions to a user with the Azure CLI, assign the AcrImageSigner role to the user, scoped to your registry. A parancs formátuma:The format of the command is:

az role assignment create --scope <registry ID> --role AcrImageSigner --assignee <user name>

Ha például magának szeretné kiosztani a szerepkört, futtathatja az alábbi parancsokat egy hitelesített Azure CLI-munkamenetben.For example, to grant yourself the role, you can run the following commands in an authenticated Azure CLI session. Módosítsa a REGISTRY értékét Azure tárolóregisztrációs adatbázisának nevére.Modify the REGISTRY value to reflect the name of your Azure container registry.

# Grant signing permissions to authenticated Azure CLI user
REGISTRY=myregistry
USER=$(az account show --query user.name --output tsv)
REGISTRY_ID=$(az acr show --name $REGISTRY --query id --output tsv)

az role assignment create --scope $REGISTRY_ID --role AcrImageSigner --assignee $USER

Egy szolgáltatásnévnek is kioszthat engedélyeket megbízható rendszerképek az adatbázisba való leküldésére.You can also grant a service principal the rights to push trusted images to your registry. A szolgáltatásnevek használata az olyan összeállítási és egyéb felügyelet nélküli rendszerek esetén bizonyul hasznosnak, amelyeknek megbízható rendszerképeket kell leküldeniük az adatbázisba.Using a service principal is useful for build systems and other unattended systems that need to push trusted images to your registry. A formátum hasonlít a felhasználói engedély kiosztása esetén használthoz, azonban az --assignee értékeként egy szolgáltatásnév-azonosítót kell megadni.The format is similar to granting a user permission, but specify a service principal ID for the --assignee value.

az role assignment create --scope $REGISTRY_ID --role AcrImageSigner --assignee <service principal ID>

A <service principal ID> lehet a szolgáltatásnév appId vagy objectId azonosítója, illetve valamely hozzá tartozó servicePrincipalName.The <service principal ID> can be the service principal's appId, objectId, or one of its servicePrincipalNames. A szolgáltatásnevek és az Azure Container Registry használatával kapcsolatos további információért tekintse meg a szolgáltatásnevek az Azure Container Registryben való hitelesítését ismertető cikket.For more information about working with service principals and Azure Container Registry, see Azure Container Registry authentication with service principals.

Fontos

A szerepkör módosítása után futtassa az acr login az Azure CLI helyi identitási jogkivonatának frissítéséhez, hogy az új szerepkörök érvénybe lépnek.After any role changes, run az acr login to refresh the local identity token for the Azure CLI so that the new roles can take effect. Az identitás szerepköreinek ellenőrzésével kapcsolatos információkért lásd: az Azure-erőforrásokhoz való hozzáférés kezelése a RBAC és az Azure CLI használatával , valamint Az Azure-erőforrások RBAC kapcsolatos hibák megoldása.For information about verifying roles for an identity, see Manage access to Azure resources using RBAC and Azure CLI and Troubleshoot RBAC for Azure resources.

Megbízható rendszerképek leküldésePush a trusted image

A megbízható rendszerkép címkéinek a tárolóregisztrációs adatbázisba való leküldéséhez engedélyezze a tartalommegbízhatóságot, és küldje le a rendszerképet a docker push paranccsal.To push a trusted image tag to your container registry, enable content trust and push the image with docker push. Amikor első alkalommal küld le egy aláírt címkét, a rendszer arra kéri, hogy hozzon létre egy jelszót a legfelső szintű aláírókulcshoz és az adattár aláírókulcsához egyaránt.The first time you push a signed tag, you're asked to create a passphrase for both a root signing key and a repository signing key. A legfelső szintű és az adattárkulcs létrehozása és tárolása egyaránt a helyi gépen történik.Both the root and repository keys are generated and stored locally on your machine.

$ docker push myregistry.azurecr.io/myimage:v1
The push refers to repository [myregistry.azurecr.io/myimage]
ee83fc5847cb: Pushed
v1: digest: sha256:aca41a608e5eb015f1ec6755f490f3be26b48010b178e78c00eac21ffbe246f1 size: 524
Signing and pushing trust metadata
You are about to create a new root signing key passphrase. This passphrase
will be used to protect the most sensitive key in your signing system. Please
choose a long, complex passphrase and be careful to keep the password and the
key file itself secure and backed up. It is highly recommended that you use a
password manager to generate the passphrase and keep it safe. There will be no
way to recover this key. You can find the key in your config directory.
Enter passphrase for new root key with ID 4c6c56a:
Repeat passphrase for new root key with ID 4c6c56a:
Enter passphrase for new repository key with ID bcd6d98:
Repeat passphrase for new repository key with ID bcd6d98:
Finished initializing "myregistry.azurecr.io/myimage"
Successfully signed myregistry.azurecr.io/myimage:v1

Miután létrejött az első olyan docker push, amelyhez engedélyezve van a tartalommegbízhatóság, a Docker-ügyfél ugyanazt a legfelső szintű kulcsot használja a következő leküldésekhez is.After your first docker push with content trust enabled, the Docker client uses the same root key for subsequent pushes. Az ugyanabban az adattárba irányuló következő leküldések esetében a rendszer már csak az adattár kulcsát kéri majd.On each subsequent push to the same repository, you're asked only for the repository key. Valahányszor új adattárba küld le megbízható rendszerképet, a rendszer arra kéri, hogy adjon meg egy jelszót egy új adattárkulcshoz.Each time you push a trusted image to a new repository, you're asked to supply a passphrase for a new repository key.

Megbízható rendszerképek lekérésePull a trusted image

Megbízható rendszerkép lekéréséhez engedélyezze a tartalommegbízhatóságot, és futtassa a docker pull parancsot a szokásos módon.To pull a trusted image, enable content trust and run the docker pull command as normal. A megbízható lemezképek lekéréséhez a AcrPull szerepkör a normál felhasználók számára elég.To pull trusted images, the AcrPull role is enough for normal users. Nincs szükség további szerepkörökre, például AcrImageSigner szerepkörre.No additional roles like an AcrImageSigner role are required. A tartalommegbízhatóságot engedélyezett felhasználók csak az aláírt címkékkel rendelkező rendszerképet kérhetik le.Consumers with content trust enabled can pull only images with signed tags. Íme egy példa egy aláírt címke lekérésére:Here's an example of pulling a signed tag:

$ docker pull myregistry.azurecr.io/myimage:signed
Pull (1 of 1): myregistry.azurecr.io/myimage:signed@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b
sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b: Pulling from myimage
8e3ba11ec2a2: Pull complete
Digest: sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b
Status: Downloaded newer image for myregistry.azurecr.io/myimage@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b
Tagging myregistry.azurecr.io/myimage@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b as myregistry.azurecr.io/myimage:signed

Ha egy tartalommegbízhatóságot engedélyezett ügyfél egy alá nem írt címkét próbál lekérni, a művelet meghiúsul:If a client with content trust enabled tries to pull an unsigned tag, the operation fails:

$ docker pull myregistry.azurecr.io/myimage:unsigned
No valid trust data for unsigned

A színfalak mögöttBehind the scenes

docker pullfuttatásakor a Docker-ügyfél ugyanazt a könyvtárat használja, mint a KÖZJEGYZŐ CLI -ben, hogy a címke – SHA-256 kivonatoló leképezést kérje a kikeresett címkéhez.When you run docker pull, the Docker client uses the same library as in the Notary CLI to request the tag-to-SHA-256 digest mapping for the tag you're pulling. Miután ellenőrizte az aláírásokat a megbízhatósági adatokon, az ügyfél utasítja a Docker-motort, hogy végezzen el egy „kivonat szerinti lekérést”.After validating the signatures on the trust data, the client instructs Docker Engine to do a "pull by digest." A lekérés során a motor az SHA-256 ellenőrzőösszeget használja a tartalom címeként a rendszerkép jegyzékének az Azure tárolóregisztrációs adatbázisból való lekéréséhez és ellenőrzéséhez.During the pull, the Engine uses the SHA-256 checksum as a content address to request and validate the image manifest from the Azure container registry.

KulcskezelésKey management

Az első megbízható rendszerkép leküldésekor a docker push kimenetében található legfelső szintű kulcs a leginkább bizalmas.As stated in the docker push output when you push your first trusted image, the root key is the most sensitive. Mindenképp készítsen biztonsági másolatot a legfelső szintű kulcsról, és tárolja biztonságos helyen.Be sure to back up your root key and store it in a secure location. Alapértelmezés szerint a Docker-ügyfél az aláírókulcsokat a következő könyvtárban tárolja:By default, the Docker client stores signing keys in the following directory:

~/.docker/trust/private

A gyökér-és adattár-kulcsok biztonsági mentéséhez tömörítse őket egy archívumban, és tárolja biztonságos helyen.Back up your root and repository keys by compressing them in an archive and storing it in a secure location. Például a Bashben:For example, in Bash:

umask 077; tar -zcvf docker_private_keys_backup.tar.gz ~/.docker/trust/private; umask 022

A helyileg létrehozott legfelső szintű és adattárkulcsokkal együtt az Azure Container Registry sok más kulcsot is létrehoz és tárol a megbízható rendszerképek leküldésekor.Along with the locally generated root and repository keys, several others are generated and stored by Azure Container Registry when you push a trusted image. A Docker tartalmi megbízhatósági implementációjának különböző kulcsainak részletes ismertetését, beleértve a további felügyeleti útmutatást is, lásd: kulcsok kezelése a tartalom megbízhatóságához a Docker dokumentációjában.For a detailed discussion of the various keys in Docker's content trust implementation, including additional management guidance, see Manage keys for content trust in the Docker documentation.

Elveszett legfelső szintű kulcsLost root key

Ha nem fér hozzá a legfelső szintű kulcshoz, az adott kulccsal aláírt címkékkel rendelkező adattárakban lévő aláírt címkékhez sem férhet hozzá.If you lose access to your root key, you lose access to the signed tags in any repository whose tags were signed with that key. Az Azure Container Registry nem képes visszaállítani az elveszett legfelső szintű kulcsokkal aláírt rendszerképcímkék elérését.Azure Container Registry cannot restore access to image tags signed with a lost root key. Az adatbázis összes megbízhatósági adatának (aláírásának) eltávolításához először tiltsa le, majd engedélyezze újra a tartalommegbízhatóságot az adatbázison.To remove all trust data (signatures) for your registry, first disable, then re-enable content trust for the registry.

Figyelmeztetés

Az adatbázis tartalommegbízhatóságának letiltása és ismételt engedélyezése az adatbázis összes adattárában törli az összes aláírt címke megbízhatósági adatait.Disabling and re-enabling content trust in your registry deletes all trust data for all signed tags in every repository in your registry. Ez a művelet nem vonható vissza – az Azure Container Registry nem képes visszaállítani a törölt megbízhatósági adatokat.This action is irreversible--Azure Container Registry cannot recover deleted trust data. A tartalommegbízhatóság letiltásával maguk a rendszerképek nem lesznek törölve.Disabling content trust does not delete the images themselves.

A tartalommegbízhatóság az adatbázisban való letiltásához lépjen az adatbázishoz az Azure Portalon.To disable content trust for your registry, navigate to the registry in the Azure portal. A házirendekterületen válassza a tartalom megbízhatósága > Letiltva > Mentéslehetőséget.Under Policies, select Content Trust > Disabled > Save. A rendszer figyelmezteti, hogy az adatbázisban lévő összes aláírás elvész.You're warned of the loss of all signatures in the registry. Az adatbázis összes aláírásának végleges törléséhez kattintson az OK gombra.Select OK to permanently delete all signatures in your registry.

Tartalommegbízhatóság letiltása egy adatbázisban az Azure Portalon

További lépésekNext steps

  • A tartalom megbízhatóságával kapcsolatos további információkért tekintse meg a tartalom megbízhatósága a Docker-ben című témakört.See Content trust in Docker for additional information about content trust. Bár több lényeges pontot is érintettünk ebben a cikkben, a tartalommegbízhatóság egy kiterjedtebb téma, amellyel részletesebben a Docker dokumentációja foglalkozik.While several key points were touched on in this article, content trust is an extensive topic and is covered more in-depth in the Docker documentation.

  • A Docker-rendszerkép létrehozásakor és leküldésekor tekintse meg az Azure-folyamatok dokumentációját.See the Azure Pipelines documentation for an example of using content trust when you build and push a Docker image.