En esta página, se describe el control de acceso con Identity and Access Management (IAM) en Artifact Registry.
Los permisos predeterminados de Artifact Registry minimizan el esfuerzo de configuración cuando se implementa una canalización de CI/CD. También puedes integrar Artifact Registry con herramientas de CI/CD de terceros y configurar los permisos y la autenticación necesarios para acceder a los repositorios.
Si usas Artifact Analysis para trabajar con metadatos de contenedores, como vulnerabilidades encontradas en las imágenes, consulta la documentación de Artifact Analysis para obtener información sobre cómo otorgar acceso para ver o administrar metadatos.Antes de comenzar
- Habilita Artifact Registry, incluida la habilitación de la API y la instalación de Google Cloud CLI.
- Si deseas aplicar permisos específicos del repositorio, entonces crea un repositorio de Artifact Registry para tus paquetes.
Descripción general
Los permisos y los roles de IAM determinan tu capacidad para crear, ver, editar o borrar datos en un repositorio de Artifact Registry.
Un rol es un conjunto de permisos. No puedes otorgar permisos principales directamente. En su lugar, les otorgas una función. Cuando otorgas un rol a una principal, le otorgas todos los permisos que el rol contiene. Puedes otorgar varios roles a la misma principal.
Permisos predeterminados deGoogle Cloud
De forma predeterminada, los siguientes permisos se aplican a los servicios de CI/CD de Google Cloud en el mismo proyecto que Artifact Registry:
- Los permisos de Cloud Build incluyen los permisos para subir y descargar artefactos.
- Compute Engine, las versiones compatibles de Google Kubernetes Engine y Cloud Run usan la cuenta de servicio predeterminada de Compute Engine, que tiene acceso de solo lectura al almacenamiento.
Si todos tus servicios se encuentran en el mismo proyecto de Google Cloud y los permisos predeterminados satisfacen tus necesidades, no necesitas configurar permisos.
Debes configurar los permisos de Artifact Registry para estos servicios si sucede lo siguiente:
- Deseas usar estos servicios para acceder a Artifact Registry en otro proyecto. En el proyecto con Artifact Registry, otorga al grupo de identidad de la carga de trabajo o a la cuenta de servicio de cada servicio el rol requerido. Si te conectas a Cloud Run, otorga el rol requerido al agente de servicio de Cloud Run.
- Usas una versión de GKE que no tiene compatibilidad integrada con la extracción de imágenes de Artifact Registry. Consulta la sección GKE para obtener instrucciones de configuración.
- Deseas que la cuenta de servicio predeterminada tenga acceso de lectura y escritura a los repositorios. Consulta la siguiente información para obtener más detalles:
- Usas una cuenta de servicio proporcionada por el usuario para los entornos de ejecución en lugar de la cuenta de servicio predeterminada. En el proyecto con Artifact Registry, otorga a tu cuenta de servicio la función requerida.
Integración con terceros
Para clientes de terceros, debes configurar permisos y autenticación.
En general, las aplicaciones que se ejecutan fuera de Google Cloud usan claves de cuentas de servicio para acceder a los recursos de Google Cloud . Sin embargo, las claves de cuenta de servicio son credenciales potentes y, si no se administran de forma adecuada, pueden representar un riesgo para la seguridad.
La federación de identidades para cargas de trabajo te permite usar Identity and Access Management para otorgar roles de IAM a identidades externas, incluida la capacidad de usar la identidad de cuentas de servicio. Con este enfoque, se elimina la carga de mantenimiento y seguridad asociada con las claves de las cuentas de servicio.
Usa la Federación de Workload Identity:
- Crea un grupo de federación de Workload Identity.
- Crea un proveedor de federación de Workload Identity.
- Otorga el rol adecuado de Artifact Registry al grupo de identidades de la carga de trabajo para permitir el acceso al repositorio.
Configura tu cliente de terceros para autenticarte con Artifact Registry.
Usa una cuenta de servicio:
- Crea una cuenta de servicio que actúe en nombre de tu aplicación o elige una cuenta de servicio existente que se use para la automatización de CI/CD.
- Otorga la función adecuada de Artifact Registry a la cuenta de servicio para proporcionar acceso al repositorio.
Configura tu cliente de terceros para autenticarte con Artifact Registry.
GitLab en Google Cloud
La integración de GitLab en Google Cloud usa la federación de identidades para cargas de trabajo para la autorización y autenticación de las cargas de trabajo de GitLab en Google Cloud sin necesidad de cuentas de servicio ni claves de cuenta de servicio. Para obtener más información sobre cómo se usa la federación de identidades para cargas de trabajo en esta asociación, consulta Google Cloud Políticas de IAM y federación de identidades para cargas de trabajo.
Para configurar la Federación de identidades de cargas de trabajo y los roles de IAM necesarios para GitLab en Google Cloud, consulta el instructivo de GitLab Google Cloud Workload Identity Federation and IAM policies.
Para conectar tu repositorio de Artifact Registry, sigue el instructivo de GitLab sobre Google Artifact Registry.
Funciones y permisos
Cada método de la API de Artifact Registry requiere que el principal que realiza la solicitud tenga los permisos necesarios para usar el recurso. Para otorgar permisos a las principales, se configuran políticas que le otorgan a la principal un rol predefinido en el recurso.
Puedes otorgar roles en el proyecto de Google Cloud o en el repositorio de Artifact Registry.
Roles predefinidos de Artifact Registry
IAM proporciona funciones predefinidas que otorgan acceso a recursos específicos de Google Cloud .
Usa los siguientes roles predefinidos para los repositorios en el dominiopkg.dev
:
Rol | Descripción |
---|---|
Lector de Artifact Registry ( roles/artifactregistry.reader ) |
Visualiza y obtén artefactos, y consulta los metadatos del repositorio. |
Escritor de Artifact Registry ( roles/artifactregistry.writer ) |
Lee y escribe artefactos. |
Administrador del repositorio de Artifact Registry ( roles/artifactregistry.repoAdmin ) |
Permite leer, escribir y borrar artefactos. |
Administrador de Artifact Registry ( roles/artifactregistry.admin ) |
Crea y administra repositorios y artefactos. |
Rol | Descripción |
---|---|
Container Registry -> Administrador de migración de Artifact Registry (roles/artifactregistry.containerRegistryMigrationAdmin ) |
Incluye todos los permisos necesarios para ejecutar las herramientas de migración. |
Escritor de creación automática al momento del envío de Artifact Registry (roles/artifactregistry.createOnPushWriter ) |
Lee y escribe artefactos. Crea repositorios de gcr.io cuando envíes a URLs de gcr.io .
|
Administrador del repositorio de Artifact Registry para envíos con creaciones (roles/artifactregistry.createOnPushRepoAdmin ) |
Permite leer, escribir y borrar artefactos. Crea repositorios de gcr.io. |
gcloud iam roles describe
para ver una lista de los permisos de cada rol.
Funciones de IAM básicas
Los roles básicos son roles muy permisivos que existían antes de la introducción de IAM. No deberías otorgar roles básicos en un entorno de producción, pero puedes otorgarlos en un entorno de desarrollo o de prueba.
Usa roles predefinidos para el acceso al repositorio siempre que sea posible, de modo que los usuarios y las cuentas de servicio solo tengan los permisos necesarios.
Para obtener más información sobre los roles básicos, consulta Referencia de los roles básicos y predefinidos de IAM.
Otorgando funciones
Otorga roles a nivel de proyecto si los mismos roles se aplican a todos los repositorios del proyecto. Si algunas cuentas requieren diferentes niveles de acceso, otorga funciones a nivel de repositorio.
Si otorgas roles en un repositorio virtual, esos roles se aplican a todos los repositorios upstream disponibles a través del repositorio virtual, independientemente de los permisos de los repositorios individuales.Si otorgas roles mediante el comando gcloud
, puedes especificar una sola vinculación de rol para un principal o realizar cambios de política a gran escala. Para ello, obtén la política de permisos de un recurso, modifícala y, luego, configura la política de permisos modificada. Para obtener más información, consulta Otorga o revoca varios roles de manera programática.
Otorga roles en todo el proyecto
Otorga una función a nivel de proyecto si los mismos permisos se aplican a todos los repositorios del proyecto.
Para agregar un usuario o una cuenta de servicio a un proyecto y otorgarle un rol de Artifact Registry, haz lo siguiente:
Console
Abre la página de IAM en la consola de Google Cloud .
Haz clic en Seleccionar un proyecto, elige el proyecto en el que se ejecuta Artifact Registry y haz clic en Abrir.
Haga clic en Add.
Ingresa una dirección de correo electrónico. Puedes agregar personas individuales, cuentas de servicio o Grupos de Google como principales.
Selecciona un rol para el principal. De acuerdo con el principio de seguridad de privilegio mínimo, considera otorgar la menor cantidad de privilegios necesarios para acceder a los recursos de Artifact Registry requeridos. Para obtener información sobre los roles y permisos predefinidos de Artifact Registry, consulta Roles predefinidos de Artifact Registry.
Haz clic en Guardar.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Para otorgar un rol a una sola principal, ejecuta el siguiente comando:
gcloud projects add-iam-policy-binding PROJECT \ --member=PRINCIPAL \ --role=ROLE
donde
- PROJECT es el ID del proyecto en el que se ejecuta Artifact Registry.
PRINCIPAL es el principal al que se agregará la vinculación. Usa el formulario
user|group|serviceAccount:email
odomain:domain
.Ejemplos:
user:test-user@gmail.com
,group:admins@example.com
,serviceAccount:test123@example.domain.com
odomain:example.domain.com
.ROLE es la función que deseas otorgar.
Para obtener más información, consulta la documentación de add-iam-policy-binding.
Para otorgar roles mediante un archivo de políticas, consulta Otorga o revoca varios roles de manera programática
Otorga roles específicos del repositorio
Otorga roles a nivel del repositorio cuando desees que los usuarios o las cuentas de servicio tengan diferentes niveles de acceso para cada repositorio del proyecto.
Console
Para otorgar acceso a un repositorio específico, haz lo siguiente:
Abre la página Repositorios en la consola de Google Cloud .
Selecciona el repositorio adecuado.
Si no se muestra el panel de información, haz clic en Mostrar panel de información en la barra de menú.
En la pestaña Permisos, haz clic en Agregar principal.
Ingresa una dirección de correo electrónico. Puedes agregar personas individuales, cuentas de servicio o Grupos de Google como principales.
Selecciona un rol para el principal. De acuerdo con el principio de seguridad de privilegio mínimo, considera otorgar la menor cantidad de privilegios necesarios para acceder a los recursos de Artifact Registry requeridos. Para obtener información sobre los roles y permisos predefinidos de Artifact Registry, consulta Funciones predefinidas de Artifact Registry.
Haz clic en Guardar.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Puedes configurar un conjunto de IAM de vinculaciones de políticas individuales o usar un archivo de políticas.
Para otorgar un rol a una sola principal, ejecuta el siguiente comando:
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION \ --member=PRINCIPAL \ --role=ROLE
donde
- REPOSITORY es el ID del repositorio.
PRINCIPAL es el principal al que se agregará la vinculación. Usa el formulario
user|group|serviceAccount:email
odomain:domain
.Ejemplos:
user:test-user@gmail.com
,group:admins@example.com
,serviceAccount:test123@example.domain.com
odomain:example.domain.com
.ROLE es la función que deseas otorgar.
LOCATION es la ubicación regional o multirregional del repositorio.
Por ejemplo, si deseas agregar una vinculación de una política de IAM para la función
roles/artifactregistry.writer
para el usuariowrite@gmail.com
con el repositoriomy-repo
en la ubicación--us-west1
, ejecuta lo siguiente:gcloud artifacts repositories add-iam-policy-binding my-repo \ --location=us-west1 --member=user:write@gmail.com --role=roles/artifactregistry.writer
Para otorgar roles con un archivo de políticas, usa el procedimiento que se describe en Otorga o revoca varios roles de forma programática con los comandos gcloud artifacts repositories get-iam-policy y gcloud artifacts repositories set-iam-policy.
Terraform
Usa el recurso google_artifact_registry_repository_iam para configurar una política de IAM. En el siguiente ejemplo, se define una cuenta de servicio con el nombre de recurso repo-account
y se le otorga acceso de lectura a un repositorio con el nombre de recurso my-repo
.
Si es la primera vez que usas Terraform para Google Cloud, consulta la página Cómo comenzar con Google Cloud en el sitio web de HashiCorp.
provider "google" {
project = "PROJECT-ID"
}
resource "google_artifact_registry_repository" "my-repo" {
provider = google-beta
location = "LOCATION"
repository_id = "REPOSITORY"
description = "DESCRIPTION"
format = "FORMAT"
}
resource "google_service_account" "repo-account" {
provider = google-beta
account_id = "ACCOUNT-ID"
display_name = "Repository Service Account"
}
resource "google_artifact_registry_repository_iam_member" "repo-iam" {
provider = google-beta
location = google_artifact_registry_repository.my-repo.location
repository = google_artifact_registry_repository.my-repo.name
role = "roles/artifactregistry.reader"
member = "serviceAccount:${google_service_account.repo-account.email}"
}
ACCOUNT-ID es el ID de la cuenta de servicio. Esta es la parte del campo de correo electrónico de la cuenta de servicio antes del símbolo @
.
Para ver ejemplos adicionales, consulta la documentación del recurso google_artifact_registry_repository_iam.
Configura el acceso público a un repositorio
Si tienes artefactos que deseas que estén disponibles para cualquier persona en Internet sin necesidad de autenticación, almacénalos en un repositorio que hagas público.
Si deseas configurar un repositorio para el acceso público de solo lectura, otorga el rol de lector de Artifact Registry al principal allUsers
. También te recomendamos
limitar las cuotas de solicitudes de los usuarios para que un solo
usuario no pueda agotar la cuota general de tu proyecto.
Console
Abre la página Repositorios en la consola de Google Cloud .
Selecciona el repositorio adecuado.
Si no se muestra el panel de información, haz clic en Mostrar panel de información en la barra de menú.
En la pestaña Permisos, haz clic en Agregar principal.
En el campo Principales nuevas, ingresa
allUsers
.Selecciona el rol de lector de Artifact Registry.
Establece un límite por usuario en las solicitudes a la API de Artifact Registry para evitar el uso inadecuado por parte de usuarios no autenticados. Consulta Cómo limitar el uso para obtener instrucciones.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Ejecuta el siguiente comando:
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION --member=allUsers --role=ROLE
donde
REPOSITORY es el ID del repositorio.
ROLE es el rol que deseas otorgar.
LOCATION es la ubicación regional o multirregional del repositorio.
Por ejemplo, para configura el repositorio
my-repo
en la ubicación--us-west1
como un repositorio público, ejecuta lo siguiente:gcloud artifacts repositories add-iam-policy-binding my-repo \ --location=us-west1 --member=allUsers --role=roles/artifactregistry.reader
Establece un límite por usuario en las solicitudes a la API de Artifact Registry para evitar el uso inadecuado por parte de usuarios no autenticados. Consulta Cómo limitar el uso para obtener instrucciones.
Revocando funciones
Para revocar el acceso a un repositorio, quita el principal de la lista de principales autorizados.
Para quitar el acceso público de un repositorio, quita el principal allUsers
.
Console
Para revocar permisos, haz lo siguiente:
Abre la página Repositorios en la consola de Google Cloud .
Selecciona el repositorio adecuado.
Si no se muestra el panel de información, haz clic en Mostrar panel de información en la barra de menú.
En la pestaña Permisos, expande el principal correspondiente. Si haces privado un repositorio público, expande el principal
allUsers
.Haz clic en Quitar principal para revocar el acceso.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Para revocar una función a nivel de proyecto, ejecuta el siguiente comando:
gcloud projects remove-iam-policy-binding PROJECT \ --member=PRINCIPAL \ --role=ROLE
- PROJECT es el ID del proyecto.
PRINCIPAL es el principal al que se quitará la vinculación. Usa el formulario
user|group|serviceAccount:email
odomain:domain
.Ejemplos:
user:test-user@gmail.com
,group:admins@example.com
,serviceAccount:test123@example.domain.com
odomain:example.domain.com
.ROLE es la función que deseas revocar.
Para revocar una función de un repositorio, ejecuta el siguiente comando:
gcloud artifacts repositories remove-iam-policy-binding REPOSITORY --location=LOCATION \ --member=PRINCIPAL \ --role=ROLE
donde
- REPOSITORY es el ID del repositorio.
PRINCIPAL es el principal al que se quitará la vinculación. Usa el formulario
user|group|serviceAccount:email
odomain:domain
.Ejemplos:
user:test-user@gmail.com
,group:admins@example.com
,serviceAccount:test123@example.domain.com
odomain:example.domain.com
.Para revocar el acceso público al repositorio, especifica el principal
allUsers
.ROLE es la función que deseas revocar.
Por ejemplo, a fin de quitar una vinculación de una política para la función
roles/artifactregistry.writer
del usuariowrite@gmail.com
con el repositoriomy-repo
en la ubicación--us-west1
, ejecuta lo siguiente:gcloud artifacts repositories remove-iam-policy-binding my-repo \ --location=us-west1 \ --member=user:write@gmail.com \ --role=roles/artifactregistry.writer
Para revocar el acceso público a
my-repo
en la ubicación--us-west1
, ejecuta el siguiente comando:gcloud artifacts repositories remove-iam-policy-binding my-repo \ --location=us-west1 \ --member=allUsers \ --role=roles/artifactregistry.reader
Otorga acceso condicional con etiquetas
Los administradores de proyectos pueden crear etiquetas para los recursos en Google Cloud y administrarlos en Resource Manager. Cuando adjuntas una etiqueta a un repositorio de Artifact Registry, los administradores pueden usarla con condiciones de IAM para otorgar acceso condicional al repositorio.
No puedes adjuntar etiquetas a artefactos individuales.
Para obtener más información, consulta la siguiente documentación:
- Administradores que configuran etiquetas y control de acceso
- Desarrolladores que adjuntan etiquetas a repositorios
Integración con los servicios de Google Cloud
Para la mayoría de las cuentas de servicio de Google Cloud , configurar el acceso a un registro solo requiere otorgar los roles de IAM adecuados.
Cuentas de servicio predeterminadas para los servicios de Google Cloud
Los servicios deGoogle Cloud , como Cloud Build o Google Kubernetes Engine, usan una cuenta de servicio predeterminada o un agente de servicio para interactuar con recursos dentro del mismo proyecto.
Debes configurar o modificar los permisos tú mismo si:
- El servicio de Google Cloud se encuentra en un proyecto diferente al de Artifact Registry.
- Los permisos predeterminados no satisfacen tus necesidades.
- Usas una cuenta de servicio proporcionada por el usuario para interactuar con Artifact Registry en lugar de la cuenta de servicio predeterminada.
- La configuración de tu política de la organización evita que se otorguen roles automáticamente a las cuentas de servicio predeterminadas.
Por lo general, las siguientes cuentas de servicio acceden a Artifact Registry. La dirección de correo electrónico de la cuenta de servicio incluye el ID o número de proyecto de Google Cloud del proyecto en el que se ejecuta el servicio.
Servicio | Cuenta de servicio | Dirección de correo electrónico |
---|---|---|
Entorno flexible de App Engine | Cuenta de servicio de App Engine | PROJECT-ID@appspot.gserviceaccount.com |
Compute Engine | Cuenta de servicio predeterminada de Compute Engine | PROJECT-NUMBER-compute@developer.gserviceaccount.com |
Cloud Build | Cuenta de servicio de Compute Engine o Cuenta de servicio heredada de Cloud Build |
Según la configuración de tu organización, la dirección de correo electrónico predeterminada de la cuenta de servicio es una de las siguientes:
|
Cloud Run |
Agente de servicio de Cloud Run Es el agente de servicio de run.googleapis.com . |
service-PROJECT-NUMBER@serverless-robot-prod.iam.gserviceaccount.com |
GKE |
Cuenta de servicio predeterminada de Compute Engine Es la cuenta de servicio predeterminada de los nodos. |
PROJECT-NUMBER-compute@developer.gserviceaccount.com |
Según la configuración de la política de la organización, es posible que a la cuenta de servicio predeterminada
se le otorgue automáticamente el rol de editor en tu
proyecto. Te recomendamos inhabilitar la concesión automática de roles; para ello,
aplica la restricción de la política de la
organización iam.automaticIamGrantsForDefaultServiceAccounts
. Si creaste tu organización después del 3 de mayo de 2024, esta
restricción se aplica de forma predeterminada.
Si inhabilitas la concesión automática de roles, debes decidir qué roles se deben otorgar a las cuentas de servicio predeterminadas y, luego, otorgar estos roles a ti mismo.
Si la cuenta de servicio predeterminada ya tiene el rol de editor, te recomendamos que reemplaces el rol de editor por roles menos permisivos.Para modificar de forma segura los roles de la cuenta de servicio, usa Policy Simulator para ver el impacto del cambio y, luego, otorga y revoca los roles adecuados.
Otorga acceso a las instancias de Compute Engine
Las instancias de VM que acceden a los repositorios deben tener configurados el permiso de acceso almacenamiento y los permisos de Artifact Registry.
Si bien el nivel de acceso de una cuenta de servicio está determinado por las funciones de IAM otorgadas a la cuenta de servicio, los niveles de acceso en una instancia de VM determinan los niveles predeterminados de OAuth para las solicitudes que se realizan a través de gcloud CLI y las bibliotecas cliente en la instancia. Como resultado, los permisos de acceso pueden limitar aún más el acceso a los métodos de la API cuando se autentica con las credenciales predeterminadas de la aplicación.
Compute Engine usa los siguientes valores predeterminados:
- La cuenta de servicio predeterminada de Compute Engine es la identidad de las instancias de VM. La dirección de correo electrónico de la cuenta de servicio tiene el sufijo @developer.gserviceaccount.com.
- La cuenta de servicio predeterminada tiene el rol de editor básico de IAM, si no inhabilitaste este comportamiento.
- Las instancias que creas con la cuenta de servicio predeterminada tienen los permisos de acceso predeterminados de Compute Engine, incluido el acceso de solo lectura al almacenamiento. Si bien el rol de editor suele otorgar acceso de escritura, el permiso de acceso de almacenamiento
read-only
limita la cuenta de servicio de la instancia a descargar artefactos solo de cualquier repositorio que se encuentre en el mismo proyecto.
Debes configurar el permiso de acceso de la cuenta de servicio si sucede lo siguiente:
- La cuenta de servicio de VM debe acceder a un repositorio en un proyecto diferente.
- La cuenta de servicio de VM debe realizar acciones que no sean la lectura de artefactos de repositorios. Por lo general, esto aplica herramientas de terceros en una VM que necesita enviar imágenes o ejecutar comandos de
gcloud
de Artifact Registry.
Para configurar los roles y establecer el permiso de acceso, haz lo siguiente:
En el proyecto que tiene la instancia de VM, obtén el nombre de la cuenta de servicio predeterminada de Compute Engine. La dirección de correo electrónico de la cuenta de servicio tiene el sufijo @developer.gserviceaccount.com.
En el proyecto que tiene el repositorio, otorga permisos para que la cuenta de servicio pueda acceder al repositorio.
Configura el permiso de acceso con la opción --scopes.
Detén la instancia de VM. Consulta Detén una instancia.
Establece el permiso de acceso mediante el siguiente comando:
gcloud compute instances set-service-account INSTANCE --scopes=SCOPE
Reemplaza SCOPE por el valor adecuado.
En Docker, se admiten las siguientes opciones:
storage-ro
: Otorga permiso de lectura solo para extraer imágenes.storage-rw
: Otorga permiso de lectura y escritura para enviar o extraer imágenes.cloud-platform
: Permite ver y administrar datos, incluidos los metadatos, en el servicio deGoogle Cloud .
Para otros formatos, debes usar el permiso
cloud-platform
.
Reinicia la instancia de VM. Consulta Inicia una instancia detenida.
Otorga acceso a los clústeres de Google Kubernetes Engine
Los clústeres y los grupos de nodos de GKE pueden extraer contenedores sin ninguna configuración adicional si se cumplen todos los siguientes requisitos:
- GKE se encuentra en el mismo proyecto que Artifact Registry.
- Los nodos usan la cuenta de servicio predeterminada, que es la cuenta de servicio predeterminada de Compute Engine.
- Los nodos se crearon con acceso de lectura al almacenamiento de la siguiente manera:
- Usar los permisos de acceso predeterminados de Compute Engine
- Otorgar el permiso de acceso
cloud-platform
o cualquier otro permiso que incluya acceso de lectura al almacenamiento
- Ejecutas una versión compatible de GKE.
Si tu entorno de GKE no cumple con estos requisitos, las instrucciones para otorgar acceso dependen de si usas la cuenta de servicio predeterminada de Compute Engine o una cuenta de servicio proporcionada por el usuario como la identidad para tus nodos.
- Cuenta de servicio predeterminada
Los siguientes requisitos de configuración se aplican a la cuenta de servicio predeterminada de Compute Engine:
Si GKE se encuentra en un proyecto distinto de Artifact Registry, otorga los permisos necesarios a la cuenta de servicio.
Si deseas enviar imágenes, interactuar con repositorios en formatos distintos de los contenedores o ejecutar comandos de
gcloud
desde el clúster, debes configurar permisos de acceso para la cuenta de servicio cuando crees el clúster o el grupo de nodos.Si no usas una versión compatible de GKE, configura imagePullSecrets.
- Cuenta de servicio proporcionada por el usuario
Si deseas usar una cuenta de servicio proporcionada por el usuario como la identidad de un clúster, debes hacer lo siguiente:
Otorga los permisos necesarios a la cuenta de servicio desde el proyecto deGoogle Cloud en el que se ejecuta Artifact Registry.
De forma predeterminada, crear un clúster o grupo de nodos con una cuenta de servicio proporcionada por el usuario otorga el permiso de acceso
cloud-platform
.Si usas la marca
--scopes
con el comando gcloud container clusters create o gcloud container node-pools create, debes incluir los alcances de acceso adecuados para usarlos con Artifact Registry.
Configura permisos de acceso
Los permisos de acceso son el método heredado que permite especificar autorización para las VMs de Compute Engine. Para extraer imágenes de los repositorios de Artifact Registry, los nodos de GKE deben tener el permiso de acceso de solo lectura al almacenamiento o algún otro permiso de acceso al almacenamiento que incluya el acceso de lectura.
Solo puedes establecer permisos de acceso cuando creas un clúster o un grupo de nodos. No puedes cambiar los permisos de acceso en los nodos existentes.
- Si usas la cuenta de servicio predeterminada de Compute Engine, GKE crea nodos con los permisos de acceso predeterminados de Compute Engine, que incluyen acceso de solo lectura al almacenamiento.
- Si usas una cuenta de servicio proporcionada por el usuario, GKE crea nodos con el permiso
cloud-platform
, que es el necesario para la mayoría de los servicios deGoogle Cloud .
Para especificar permisos de acceso cuando creas un clúster, ejecuta el siguiente comando:
gcloud container clusters create NAME --scopes=SCOPES
Para especificar permisos de acceso cuando creas un grupo de nodos, ejecuta el siguiente comando:
gcloud container node-pools create NAME --scopes=SCOPES
Reemplaza los siguientes valores:
- NAME es el nombre del clúster o grupo de nodos.
SCOPES es una lista separada por comas de los permisos de acceso que se otorgarán.
Para acceder a los repositorios de Docker, usa uno de los siguientes permisos de acceso:
storage-ro
: Otorga permiso de solo lectura para extraer imágenes.storage-rw
: Otorga permiso de lectura y escritura para enviar o extraer imágenes.cloud-platform
: Permite ver y administrar datos, incluidos los metadatos, en el servicio deGoogle Cloud .Para acceder a otros repositorios, debes usar el permiso
cloud-platform
.
Para obtener una lista completa de los permisos, consulta la documentación de gcloud container clusters create o gcloud container node-pools create.
Para obtener más información sobre los permisos que puedes configurar cuando creas un clúster nuevo, consulta la documentación del comando gcloud container clusters create.
Cómo configurar un imagePullSecret
Para configurar un imagePullSecret
, haz lo siguiente:
En el proyecto que tiene GKE, busca la cuenta de servicio predeterminada de Compute Engine. La dirección de correo electrónico de la cuenta tiene el sufijo @developer.gserviceaccount.com.
Descarga la clave de la cuenta de servicio para la cuenta de servicio.
En el proyecto que tiene el repositorio, verifica que haber otorgado permisos al repositorio.
En el proyecto que tiene el clúster, crea un secreto
imagePullSecret
llamadoartifact-registry
con la clave de la cuenta de servicio.kubectl create secret docker-registry artifact-registry \ --docker-server=https://LOCATION-docker.pkg.dev \ --docker-email=SERVICE-ACCOUNT-EMAIL \ --docker-username=_json_key \ --docker-password="$(cat KEY-FILE)"
Reemplaza lo siguiente:
- LOCATION es la ubicación regional o multirregional del repositorio.
- SERVICE-ACCOUNT-EMAIL es la dirección de correo electrónico de la cuenta de servicio de Compute Engine.
- KEY-FILE es el nombre del archivo de claves de la cuenta de servicio. Por ejemplo, "key.json".
Abre tu cuenta de servicio predeterminada:
kubectl edit serviceaccount default --namespace default
Cada espacio de nombres en tu clúster de Kubernetes tiene una cuenta de servicio predeterminada llamada
default
. Esta cuenta de servicio predeterminada se usa para extraer la imagen del contenedor.Agrega el secreto
imagePullSecret
recién creado a tu cuenta de servicio predeterminada:imagePullSecrets: - name: artifact-registry
Tu cuenta de servicio debería verse así:
apiVersion: v1 kind: ServiceAccount metadata: name: default namespace: default ... secrets: - name: default-token-zd84v # The secret you created: imagePullSecrets: - name: artifact-registry
Ahora, todos los Pods nuevos creados en el espacio de nombres default
actual tendrán definido el secreto imagePullSecret
.
Cuenta de servicio de Artifact Registry
El agente de servicio de Artifact Registry es una cuenta de servicio administrada por Google que actúa en nombre de Artifact Registry cuando interactúa con los servicios de Google Cloud. Para obtener más información sobre la cuenta y sus permisos, consulta Cuenta de servicio de Artifact Registry.
¿Qué sigue?
Después de configurar los permisos, obtén más información sobre cómo trabajar con los artefactos.
- Imágenes de contenedor: Docker, Helm
- Paquetes de lenguajes: Java, Node.js, Python y Go
- Paquetes de SO: Debian, RPM