Důvěryhodnost obsahu ve službě Azure Container Registry

Azure Container Registry implementuje model důvěryhodnosti obsahu Dockeru, který umožňuje nasdílení a vyžádání podepsaných imagí. Tento článek vám pomůže začít povolovat důvěryhodnost obsahu v registrech kontejnerů.

Omezení

• Token s oprávněními v oboru úložiště v současné době nepodporuje docker push a pull podepsaných imagí.

Princip fungování důvěryhodnosti obsahu

V každém distribuovaném systému navrženém s ohledem na zabezpečení je důležité ověřovat zdroj i integritu dat, která do systému přicházejí. Příjemci dat potřebují mít možnost ověřit vydavatele (zdroj) dat i to, že po publikování nedošlo ke změně dat (integrita).

Jako vydavateli imagí vám důvěryhodnost obsahu umožňuje podepisovat image, které odesíláte do svého registru. Příjemci vašich imagí (lidé nebo systémy stahující image z vašeho registru) můžou nakonfigurovat své klienty tak, aby stahovali pouze podepsané image. Když příjemci imagí stáhnou podepsanou image, jejich klient Dockeru ověří integritu image. V tomto modelu mají příjemci jistotu, že jste podepsané image ve vašem registru skutečně publikovali vy a že po publikování nedošlo k jejich změně.

Důvěryhodné image

Důvěryhodnost obsahu pracuje se značkami v úložišti. Úložiště imagí můžou obsahovat image s podepsanými i nepodepsanými značkami. Například můžete podepsat pouze image myimage:stable a myimage:latest, ale ne image myimage:dev.

Podpisové klíče

Důvěryhodnost obsahu se spravuje prostřednictvím používání sady kryptografických podpisových klíčů. Tyto klíče jsou přidružené ke konkrétnímu úložišti v registru. Klienti Dockeru a váš registr při správě důvěryhodnosti značek v úložišti používají několik typů podpisových klíčů. Pokud povolíte důvěryhodnost obsahu a integrujete ji do svého kanálu publikování a využívání kontejnerů, musíte tyto klíče pečlivě spravovat. Další informace najdete v pozdější části Správa klíčů v tomto článku a v tématu Správa klíčů pro důvěryhodnost obsahu v dokumentaci k Dockeru.

Povolení důvěryhodnosti obsahu u registru

Prvním krokem je povolení důvěryhodnosti obsahu na úrovni registru. Jakmile povolíte důvěryhodnost obsahu, klienti (uživatelé nebo služby) budou do vašeho registru moct odesílat podepsané image. Po povolení důvěryhodnosti obsahu v registru nedojde k omezení možnosti využívat registr pouze na zákazníky s povolenou důvěryhodností obsahu. Příjemci bez povolené důvěryhodnosti obsahu můžou váš registr normálně využívat i nadále. Příjemcům, kteří ve svých klientech povolili důvěryhodnost obsahu, se však zobrazí pouze podepsané image ve vašem registru.

Pokud chcete pro svůj registr povolit důvěryhodnost obsahu, nejprve přejděte do tohoto registru na webu Azure Portal. V části Zásady vyberte Uložit povolenou>důvěryhodnost>obsahu. V Azure CLI můžete také použít příkaz az acr config content-trust update .

Povolení důvěryhodnosti obsahu u klientů

Aby bylo možné pracovat s důvěryhodnými imagemi, musí vydavatelé i příjemci imagí povolit důvěryhodnost obsahu pro své klienty Dockeru. Jako vydavatel můžete podepisovat image, které odešlete do registru s povolenou důvěryhodností obsahu. Jako příjemci se vám po povolení důvěryhodnosti obsahu budou v registru zobrazovat pouze podepsané image. V klientech Dockeru je důvěryhodnost obsahu ve výchozím nastavení zakázaná, ale můžete ji povolit pro jednotlivé relace prostředí nebo příkazy.

Pokud chcete povolit důvěryhodnost obsahu v relaci prostředí, nastavte proměnnou prostředí DOCKER_CONTENT_TRUST na hodnotu 1. Příklad v prostředí Bash:

# Enable content trust for shell session
export DOCKER_CONTENT_TRUST=1

Pokud místo toho chcete povolit nebo zakázat důvěryhodnost obsahu pro jeden příkaz, řada příkazů Dockeru podporuje argument --disable-content-trust. Povolení důvěryhodnosti obsahu pro jeden příkaz:

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

Pokud jste povolili důvěryhodnost obsahu v relaci prostředí a chcete ji zakázat pro jeden příkaz:

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

Udělení oprávnění k podepisování imagí

Do vašeho registru můžou odesílat důvěryhodné image pouze uživatelé nebo systémy, kterým k tomu udělíte oprávnění. Pokud chcete uživateli (nebo systému pomocí instančního objektu udělit důvěryhodná oprávnění k nabízení imagí), udělte jeho identitám AcrImageSigner Microsoft Entra roli. To je kromě AcrPush (nebo ekvivalentní) role vyžadované pro odesílání imagí do registru. Podrobnosti najdete v tématu Role a oprávnění služby Azure Container Registry.

Následují podrobnosti o udělení role AcrImageSigner na webu Azure Portal a v Azure CLI.

portál Azure

1. Vyberte Řízení přístupu (IAM) .

2. Kliknutím na Přidat>Přidat přiřazení role otevřete stránku Přidat přiřazení role.

3. Přiřaďte následující roli. V tomto příkladu je role přiřazena jednotlivým uživatelům. Podrobný postup najdete v tématu Přiřazování rolí Azure s využitím webu Azure Portal.

   Nastavení	Hodnota
   Role	AcrImageSigner
   Přiřadit přístup k	Uživatelská
   Členové	Alan

   

Azure CLI

Pokud chcete uživateli udělit oprávnění k podpisování pomocí Azure CLI, přiřaďte uživateli roli AcrImageSigner s oborem vymezeným vaším registrem. Příkaz má tento formát:

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

Pokud chcete například udělit uživateli bez oprávnění správce roli, můžete v ověřené relaci Azure CLI spustit následující příkazy. Hodnotu REGISTRY upravte tak, aby odpovídala názvu vašeho registru kontejneru Azure.

# 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

Oprávnění k odesílání důvěryhodných imagí do vašeho registru můžete udělit také instančnímu objektu. Použití instančního objektu je užitečné u sestavovacích a dalších bezobslužných systémů, které potřebují odesílat důvěryhodné image do vašeho registru. Formát je podobný jako při udělování oprávnění uživateli, ale jako hodnotu --assignee použijte ID instančního objektu.

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

Hodnota <service principal ID> může být ID aplikace, ID objektu nebo jeden z hlavních názvů služby instančního objektu. Další informace o práci s instančními objekty a službou Azure Container Registry najdete v tématu Ověřování ve službě Azure Container Registry pomocí instančních objektů.

Odeslání důvěryhodné image

Pokud chcete do registru kontejneru odeslat značku důvěryhodné image, povolte důvěryhodnost obsahu a odešlete image pomocí příkazu docker push. Po prvním nasdílení změn pomocí podepsané značky se zobrazí výzva k vytvoření přístupového hesla pro kořenový podpisový klíč i podpisový klíč úložiště. Kořenový podpisový klíč i podpisový klíč úložiště se vygenerují a uloží místně na vašem počítači.

$ 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

Po prvním spuštění příkazu docker push s povolenou důvěryhodností obsahu bude klient Dockeru používat stejný kořenový klíč i pro další odeslání. Při každém dalším odeslání do stejného úložiště se zobrazí pouze výzva k zadání klíče úložiště. Při každém odeslání důvěryhodné image do nového úložiště se zobrazí výzva k zadání hesla pro nový klíč úložiště.

Stažení důvěryhodné image

Pokud chcete stáhnout důvěryhodnou image, povolte důvěryhodnost obsahu a jako obvykle spusťte příkaz docker pull. Pro vyžádání důvěryhodných imagí AcrPull stačí role normálním uživatelům. Nejsou vyžadovány žádné další role, jako je AcrImageSigner role. Příjemci s povolenou důvěryhodností obsahu můžou stahovat pouze image s podepsanou značkou. Tady je příklad stažení podepsané značky:

$ 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

Pokud se klient s povolenou důvěryhodností obsahu pokusí vyžádat nepodepsanou značku, operace selže s chybou podobnou následující:

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

Informace pro pokročilé uživatele

Po spuštění příkazu docker pull si klient Dockeru pomocí stejné knihovny jako v rozhraní příkazového řádku Notary vyžádá mapování stahované značky na hodnotu hash SHA-256. Po ověření podpisů v datech důvěryhodnosti klient dává modulu Dockeru pokyn, aby udělal "pull by digest". Během vyžádání obsahu modul používá kontrolní součet SHA-256 jako adresu obsahu k vyžádání a ověření manifestu image z registru kontejneru Azure.

Správa klíčů

Jak je uvedeno ve výstupu příkazu docker push při odeslání první důvěryhodné image, nejcitlivější je kořenový klíč. Nezapomeňte si kořenový klíč zálohovat a uložte ho na bezpečné místo. Klient Dockeru ve výchozím nastavení ukládá podpisové klíče do následujícího adresáře:

~/.docker/trust/private

Zálohujte své kořenové klíče a klíče úložiště tak, že je zkomprimujte v archivu a uložíte ho do zabezpečeného umístění. Příklad v prostředí Bash:

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

Kromě místně vygenerovaného kořenového klíče a klíče úložiště služba Azure Container Registry při odeslání důvěryhodné image vygeneruje a uloží několik dalších klíčů. Podrobný popis různých klíčů v implementaci důvěryhodnosti obsahu Dockeru, včetně dalších pokynů pro správu, najdete v tématu Správa klíčů pro důvěryhodnost obsahu v dokumentaci k Dockeru.

Ztracený kořenový klíč

Pokud ztratíte přístup ke svému kořenovému klíči, ztratíte tím přístup ke značkám podepsaným tímto klíčem ve všech úložištích. Azure Container Registry nemůže obnovit přístup ke značkám imagí podepsaným ztraceným kořenovým klíčem. Pokud chcete ze svého registru odebrat veškerá data důvěryhodnosti (podpisy), nejprve pro registr zakažte a pak znovu povolte důvěryhodnost obsahu.

Pokud chcete pro svůj registr zakázat důvěryhodnost obsahu, přejděte do tohoto registru na webu Azure Portal. V části Zásady vyberte Uložit zakázaný>vztah důvěryhodnosti>obsahu. Zobrazí se upozornění na ztrátu všech podpisů v registru. Výběrem OK trvale odstraníte všechny podpisy ve vašem registru.

Další kroky

• Další informace o důvěryhodnosti obsahu, včetně příkazů důvěryhodnosti dockeru a delegování důvěryhodnosti, najdete v tématu Důvěryhodnost obsahu v Dockeru. Přestože se tento článek zabýval několika klíčovými body, důvěryhodnost obsahu je rozsáhlé téma, kterému se podrobněji věnuje dokumentace k Dockeru.

• Příklad použití důvěryhodnosti obsahu při sestavování a nasdílení image Dockeru najdete v dokumentaci ke službě Azure Pipelines.