A tartalmak megbízhatósága az Azure Container Registryben

  • Cikk

Az Azure Container Registry implementálja a Docker tartalommegbízhatósági modelljét, lehetővé téve az aláírt képek leküldését és lekérését. Ez a cikk bemutatja a tartalommegbízhatóság engedélyezését a tárolóregisztrációs adatbázisokban.

Megjegyzés:

A tartalommegbízhatóság az Azure Container Registry prémium szolgáltatási szintjének egyik funkciója.

Korlátozások

  • Az adattár hatókörű engedélyekkel rendelkező jogkivonat jelenleg nem támogatja az aláírt képek Docker-leküldését és lekérését.

A tartalommegbízhatóság működése

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. 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).

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. 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. 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. 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.

Megjegyzés:

Az Azure Container Registry (ACR) nem támogatja acr import a Docker Content Trust (DCT) szolgáltatással aláírt képek importálását. A terv szerint az aláírások nem láthatók az importálás után, és a jegyző v2 ezeket az aláírásokat összetevőkként tárolja.

Megbízható rendszerképek

A tartalommegbízhatóság az adattárak címkéivel is használható. A rendszerkép-adattárak aláírt és nem aláírt címkékkel rendelkező rendszerképeket egyaránt tartalmazhatnak. 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.

Aláírókulcsok

A tartalommegbízhatóság titkosítási aláírókulcsok használatával valósul meg. A kulcsok egy adott adattárral vannak társítva az adatbázisban. 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. 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. További információt a jelen cikk későbbi, Kulcskezelés című szakaszában, valamint a Docker dokumentációjának a tartalommegbízhatóság kulcsainak kezelését leíró részében talál.

Tipp.

Ez a Docker tartalommegbízhatósági modelljének összefoglaló jellegű áttekintése volt. A tartalommegbízhatóság részletes leírásáért tekintse meg a Docker tartalommegbízhatóságát ismertető cikket.

Tárolóregisztrációs adatbázis tartalommegbízhatóságának engedélyezése

Első lépésként az adatbázis szintjén kell engedélyezni a tartalommegbízhatóságot. 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. 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. Azok a felhasználók, akiknél nincs engedélyezve, továbbra is a szokott módon használhatják az adatbázist. 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.

A tartalommegbízhatóság az adatbázisban való engedélyezéséhez először lépjen az adatbázishoz az Azure Portalon. A Szabályzatok csoportban válassza a Tartalommegbízhatósági>kompatibilis mentés lehetőséget.> Az az acr config content-trust update parancsot az Azure CLI-ben is használhatja.

Screenshot shows enabling content trust for a registry in the Azure portal.

A tartalommegbízhatóság engedélyezése az ügyfeleken

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. 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. 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. 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ő.

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. Például a Bash-felületen:

# 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. A tartalommegbízhatóság engedélyezése egyetlen parancsra:

# 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:

# 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ása

Csak azok a felhasználók és rendszerek küldhetnek le megbízható rendszerképeket az adatbázisba, amelyeknek engedélyezte ezt. Ha megbízható rendszerkép-leküldési engedélyt szeretne adni egy felhasználónak (vagy egy szolgáltatásnevet használó rendszernek), adja meg a Microsoft Entra-identitásnak a szerepkört AcrImageSigner . Ez a rendszerképek beállításjegyzékbe való küldéséhez szükséges (vagy azzal egyenértékű) szerepkörön kívül AcrPush van. További részletekért tekintse meg az Azure Container Registry szerepköreit és engedélyeit.

Fontos

Nem adhat megbízható képküldési engedélyt a következő felügyeleti fiókoknak:

Megjegyzés:

2021 júliusától a szerepkör magában AcrImageSigner foglalja a Microsoft.ContainerRegistry/registries/sign/write műveletet és az Microsoft.ContainerRegistry/registries/trustedCollections/write adatműveletet is.

Az alábbiakban ismertetjük az AcrImageSigner szerepkör az Azure Portalon és az Azure CLI felületen való kiosztásának részleteit.

Azure Portal

  1. Select Access control (IAM).

  2. Válassza a Szerepkör-hozzárendelés hozzáadása>lehetőséget a Szerepkör-hozzárendelés hozzáadása lap megnyitásához.

  3. Rendelje hozzá a következő szerepkört. Ebben a példában a szerepkör egy adott felhasználóhoz van rendelve. A részletes lépésekért tekintse meg az Azure-szerepköröknek az Azure Portalon történő hozzárendelését ismertető cikket.

    Beállítás Value
    Role AcrImageSigner
    Hozzáférés hozzárendelése a következőhöz: User
    Tagok Alain

    Add role assignment page in Azure portal.

Azure 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. A parancs formátuma:

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

Ha például rendszergazdai szerepkört szeretne adni egy nem rendszergazda felhasználónak, a következő parancsokat futtathatja egy hitelesített Azure CLI-munkamenetben. Módosítsa a REGISTRY értékét Azure tárolóregisztrációs adatbázisának nevére.

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

az role assignment create --scope $REGISTRY_ID --role AcrImageSigner --assignee azureuser@contoso.com

Egy szolgáltatásnévnek is kioszthat engedélyeket megbízható rendszerképek az adatbázisba való leküldésére. 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. 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.

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. 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.

Fontos

A szerepkör-módosítások után futtassa az acr login a helyi identitás jogkivonatának frissítését az Azure CLI-hez, hogy az új szerepkörök érvénybe léphessenek. Az identitáshoz tartozó szerepkörök ellenőrzéséről további információt az Azure CLI használatával történő Azure-szerepkör-hozzárendelések hozzáadása vagy eltávolítása, valamint az Azure RBAC hibaelhárítása című témakörben talál.

Megbízható rendszerképek leküldése

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. Miután az aláírt címkével végzett leküldés első alkalommal befejeződött, a rendszer arra kéri, hogy hozzon létre egy jelszót a fő aláíró kulcshoz és egy adattár-aláíró kulcshoz is. A legfelső szintű és az adattárkulcs létrehozása és tárolása egyaránt a helyi gépen történik.

$ 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. 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. 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.

Megbízható rendszerképek lekérése

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. Megbízható képek lekéréséhez a AcrPull szerepkör elegendő a normál felhasználók számára. Nincs szükség további szerepkörökre, például szerepkörökre AcrImageSigner . A tartalommegbízhatóságot engedélyezett felhasználók csak az aláírt címkékkel rendelkező rendszerképet kérhetik le. Íme egy példa egy aláírt címke lekérésére:

$ 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élyező ügyfél aláíratlan címkét próbál lekérni, a művelet az alábbihoz hasonló hibával meghiúsul:

$ docker pull myregistry.azurecr.io/myimage:unsigned
Error: remote trust data does not exist

A színfalak mögött

A docker pull futtatásakor a Docker-ügyfél ugyanazt a kódtárat használja a lehívott címke címke–SHA-256 kivonatoló leképezésének igényléséhez, mint a Notary CLI esetében. Miután ellenőrizte az aláírásokat a megbízhatósági adatokon, az ügyfél arra utasítja a Docker Engine-t, hogy végezze el a "lekérés kivonatolással" parancsot. A lekérés során a motor az SHA-256 ellenőrzőösszeget használja tartalomcímként a rendszerkép-jegyzék azure-tárolóregisztrációs adatbázisból való lekéréséhez és érvényesítéséhez.

Megjegyzés:

Az Azure Container Registry hivatalosan nem támogatja a közjegyzői cli-t, de kompatibilis a Docker Desktopban található Közjegyzői kiszolgáló API-val. Jelenleg a Jegyző 0.6.0-s verziója ajánlott.

Kulcskezelés

Az első megbízható rendszerkép leküldésekor a docker push kimenetében található legfelső szintű kulcs a leginkább bizalmas. Mindenképp készítsen biztonsági másolatot a legfelső szintű kulcsról, és tárolja biztonságos helyen. Alapértelmezés szerint a Docker-ügyfél az aláírókulcsokat a következő könyvtárban tárolja:

~/.docker/trust/private

A gyökér- és adattárkulcsok biztonsági mentéséhez tömörítse őket egy archívumba, és biztonságos helyen tárolja őket. Például a Bashben:

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. A Docker tartalommegbízhatósági megoldásiban lévő különféle kulcsok részletes ismertetéséért, valamint további felügyeleti útmutatásért lásd a Docker dokumentációjának a tartalommegbízhatóság kulcsainak kezelését ismertető szakaszát.

Elveszett legfelső szintű kulcs

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á. 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. 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.

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. 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. A tartalommegbízhatóság letiltásával maguk a rendszerképek nem lesznek törölve.

A tartalommegbízhatóság az adatbázisban való letiltásához lépjen az adatbázishoz az Azure Portalon. A Szabályzatok csoportban válassza a Tartalommegbízhatóság>letiltva>mentés lehetőséget. A rendszer figyelmezteti, hogy az adatbázisban lévő összes aláírás elvész. Az adatbázis összes aláírásának végleges törléséhez kattintson az OK gombra.

Disabling content trust for a registry in the Azure portal

Következő lépések