GSP493

Descripción general

En este lab, se explica cómo usar y depurar el control de acceso basado en roles (RBAC) en un clúster de Kubernetes Engine.

Si bien las definiciones de recursos del RBAC son estándar en todas las plataformas de Kubernetes, es necesario entender su interacción con los proveedores de autorización y autenticación subyacentes cuando compila en cualquier proveedor de servicios en la nube.

El RBAC es un mecanismo de seguridad potente que brinda una gran flexibilidad en cuanto a la forma en que se restringen las operaciones dentro de un clúster. En este lab, se presentarán dos casos de uso del RBAC:

1. Asignar diferentes permisos a los usuarios arquetipo, es decir, propietarios y auditores
2. Otorgar acceso limitado a la API a una aplicación que se ejecuta dentro de tu clúster

Dado que la flexibilidad del RBAC puede, en ocasiones, generar reglas complejas, en la situación 2 se incluyen pasos comunes para la solución de problemas del RBAC.

Arquitectura

Este lab se enfoca en el uso del RBAC dentro de un clúster de Kubernetes Engine. Se demuestra cómo se pueden otorgar distintos niveles de privilegios de clúster a diferentes usuarios arquetipo. Aprovisionarás dos cuentas de servicio para representar a los usuarios arquetipo y tres espacios de nombres: desarrollo, prueba y producción. El arquetipo "propietario" tendrá acceso de lectura/escritura a los tres espacios de nombres, mientras que el arquetipo "auditor" tendrá acceso de solo lectura y se lo restringirá al espacio de nombres de desarrollo.

Los ingenieros de GKE Helmsman crearon este lab para ayudarte a comprender mejor cómo usar el control de acceso basado en roles en GKE. Puedes ver esta demostración en GitHub. Te invitamos a hacer cualquier aporte que creas conveniente.

Configuración y requisitos

Antes de hacer clic en el botón Comenzar lab

Lee estas instrucciones. Los labs cuentan con un temporizador que no se puede pausar. El temporizador, que comienza a funcionar cuando haces clic en Comenzar lab, indica por cuánto tiempo tendrás a tu disposición los recursos de Google Cloud.

Este lab práctico te permitirá realizar las actividades correspondientes en un entorno de nube real, no en uno de simulación o demostración. Para ello, se te proporcionan credenciales temporales nuevas que utilizarás para acceder a Google Cloud durante todo el lab.

Para completar este lab, necesitarás lo siguiente:

• Acceso a un navegador de Internet estándar. Se recomienda el navegador Chrome.

Nota: Usa una ventana del navegador privada o de incógnito (opción recomendada) para ejecutar el lab. Así evitarás conflictos entre tu cuenta personal y la cuenta de estudiante, lo que podría generar cargos adicionales en tu cuenta personal.

• Tiempo para completar el lab (recuerda que, una vez que comienzas un lab, no puedes pausarlo).

Nota: Usa solo la cuenta de estudiante para este lab. Si usas otra cuenta de Google Cloud, es posible que se apliquen cargos a esa cuenta.

Cómo iniciar tu lab y acceder a la consola de Google Cloud

1. Haz clic en el botón Comenzar lab. Si debes pagar por el lab, se abrirá un diálogo para que selecciones la forma de pago. A la izquierda, se encuentra el panel Detalles del lab, que tiene estos elementos:

   • El botón para abrir la consola de Google Cloud
   • El tiempo restante
   • Las credenciales temporales que debes usar para el lab
   • Otra información para completar el lab, si es necesaria

2. Haz clic en Abrir la consola de Google Cloud (o haz clic con el botón derecho y selecciona Abrir el vínculo en una ventana de incógnito si ejecutas el navegador Chrome).

   El lab inicia recursos y abre otra pestaña en la que se muestra la página de acceso.

   Sugerencia: Ordena las pestañas en ventanas separadas, una junto a la otra.

   Nota: Si ves el diálogo Elegir una cuenta, haz clic en Usar otra cuenta.

3. De ser necesario, copia el nombre de usuario a continuación y pégalo en el diálogo Acceder.

   {{{user_0.username | "Username"}}}

   También puedes encontrar el nombre de usuario en el panel Detalles del lab.

4. Haz clic en Siguiente.

5. Copia la contraseña que aparece a continuación y pégala en el diálogo Te damos la bienvenida.

   {{{user_0.password | "Password"}}}

   También puedes encontrar la contraseña en el panel Detalles del lab.

6. Haz clic en Siguiente.

   Importante: Debes usar las credenciales que te proporciona el lab. No uses las credenciales de tu cuenta de Google Cloud. Nota: Usar tu propia cuenta de Google Cloud para este lab podría generar cargos adicionales.

7. Haz clic para avanzar por las páginas siguientes:

   • Acepta los Términos y Condiciones.
   • No agregues opciones de recuperación o autenticación de dos factores (esta es una cuenta temporal).
   • No te registres para obtener pruebas gratuitas.

Después de un momento, se abrirá la consola de Google Cloud en esta pestaña.

Nota: Para acceder a los productos y servicios de Google Cloud, haz clic en el menú de navegación o escribe el nombre del servicio o producto en el campo Buscar.

Activa Cloud Shell

Cloud Shell es una máquina virtual que cuenta con herramientas para desarrolladores. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud. Cloud Shell proporciona acceso de línea de comandos a tus recursos de Google Cloud.

1. Haz clic en Activar Cloud Shell en la parte superior de la consola de Google Cloud.

2. Haz clic para avanzar por las siguientes ventanas:

   • Continúa en la ventana de información de Cloud Shell.
   • Autoriza a Cloud Shell para que use tus credenciales para realizar llamadas a la API de Google Cloud.

Cuando te conectes, habrás completado la autenticación, y el proyecto estará configurado con tu Project_ID, . El resultado contiene una línea que declara el Project_ID para esta sesión:

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud es la herramienta de línea de comandos de Google Cloud. Viene preinstalada en Cloud Shell y es compatible con la función de autocompletado con tabulador.

3. Puedes solicitar el nombre de la cuenta activa con este comando (opcional):

gcloud auth list

4. Haz clic en Autorizar.

Resultado:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. Puedes solicitar el ID del proyecto con este comando (opcional):

gcloud config list project

Resultado:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Nota: Para obtener toda la documentación de gcloud, en Google Cloud, consulta la guía con la descripción general de gcloud CLI.

Configura tu región y zona

Algunos recursos de Compute Engine se encuentran en regiones y zonas. Una región es una ubicación geográfica específica donde puedes ejecutar tus recursos. Cada región tiene una o más zonas.

Para obtener más información sobre las regiones y zonas y ver una lista de todas ellas, consulta esta documentación.

Ejecuta el siguiente comando para configurar una región y zona para tu lab (puedes usar la región/zona más adecuada para tu caso):

gcloud config set compute/region {{{project_0.default_region|REGION}}} gcloud config set compute/zone {{{project_0.default_zone|ZONE}}}

Tarea 1: Verifica el clúster

Confirma el clúster creado previamente la consola. Ve al menú de navegación > Kubernetes Engine > Clústeres y haz clic en el clúster "rbac-demo-cluster". Asegúrate de que esté inhabilitada la autorización heredada para el nuevo clúster.

Tarea 2: Situación 1: Asignación de permisos por usuario arquetipo

Rol de IAM

Se creó un rol llamado kube-api-ro-xxxxxxxx (en el que xxxxxxxx es una cadena aleatoria) con los siguientes permisos como parte de la configuración de Terraform en iam.tf. Estos son los permisos mínimos necesarios para cualquier usuario que requiera acceso a la API de Kubernetes.

• container.apiServices.get
• container.apiServices.list
• container.clusters.get
• container.clusters.getCredentials

Simula usuarios

Se crearon tres cuentas de servicio para que actúen como usuarios de prueba:

• administrador: tiene permisos de administrador sobre el clúster y todos los recursos.
• propietario: tiene permisos de lectura y escritura sobre los recursos comunes del clúster.
• auditor: tiene permisos de solo lectura únicamente dentro del espacio de nombres de desarrollo.

1. Ejecuta este comando:

gcloud iam service-accounts list

La secuencia de comandos de Terraform aprovisionó tres hosts de prueba. En cada nodo, se instaló y configuró kubectl y gcloud para simular un usuario arquetipo diferente.

• gke-tutorial-admin: kubectl y gcloud se autenticaron como administradores del clúster.
• gke-tutorial-owner: simula la cuenta owner
• gke-tutorial-auditor: simula la cuenta auditor

2. Ejecuta este comando:

gcloud compute instances list

Resultado:

NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS rbac-demo-cluster-default-pool-a9cd3468-4vpc {{{project_0.default_zone|ZONE}}} n1-standard-1 10.0.96.5 RUNNING rbac-demo-cluster-default-pool-a9cd3468-b47f {{{project_0.default_zone|ZONE}}} n1-standard-1 10.0.96.6 RUNNING rbac-demo-cluster-default-pool-a9cd3468-rt5p {{{project_0.default_zone|ZONE}}} n1-standard-1 10.0.96.7 RUNNING gke-tutorial-auditor {{{project_0.default_zone|ZONE}}} f1-micro 10.0.96.4 35.224.148.28 RUNNING gke-tutorial-admin {{{project_0.default_zone|ZONE}}} f1-micro 10.0.96.3 35.226.237.142 RUNNING gke-tutorial-owner {{{project_0.default_zone|pZONE}}} f1-micro 10.0.96.2 35.194.58.130 RUNNING

Crea las reglas de RBAC

Crea los espacios de nombres, roles y vinculaciones de roles iniciando sesión en la instancia de administrador y aplicando el manifiesto rbac.yaml.

1. Establece una conexión SSH al administrador:

gcloud compute ssh gke-tutorial-admin Nota: Ignora el error relacionado con el complemento de autenticación de GCP.

Las versiones existentes de kubectl y los clientes personalizados de Kubernetes contienen código específico del proveedor para administrar la autenticación entre el cliente y Google Kubernetes Engine. A partir de la versión 1.26, este código ya no se incluirá como parte del software de código abierto de kubectl. Los usuarios de GKE deberán descargar y usar un complemento de autenticación independiente para generar tokens específicos de GKE. Este nuevo objeto binario, gke-gcloud-auth-plugin, usa el mecanismo Complemento de credenciales Client-go de Kubernetes para extender la autenticación de kubectl y respaldar GKE. Para obtener más información, revisa la siguiente documentación.

Sigue estos pasos para que kubectl use el nuevo complemento de objeto binario para la autenticación, en lugar del código específico del proveedor.

2. Luego de conectarte, ejecuta el siguiente comando para instalar el gke-gcloud-auth-plugin en la VM.

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin

3. Establece export USE_GKE_GCLOUD_AUTH_PLUGIN=True en ~/.bashrc:

echo "export USE_GKE_GCLOUD_AUTH_PLUGIN=True" >> ~/.bashrc

4. Ejecuta el siguiente comando:

source ~/.bashrc

5. Ejecuta este comando para forzar la configuración de este clúster, de manera que se actualice a la configuración del Complemento de credenciales Client-go.

gcloud container clusters get-credentials rbac-demo-cluster --zone {{{project_0.default_zone|ZONE}}}

Si la operación es exitosa, deberías ver este mensaje emergente:

Kubeconfig entry generated for dev-cluster.

El clúster recién creado estará disponible para los comandos estándar de kubectl en el host de bastión.

6. Crea los espacios de nombres, roles y vinculaciones:

kubectl apply -f ./manifests/rbac.yaml

Resultado:

namespace/dev created namespace/prod created namespace/test created role.rbac.authorization.k8s.io/dev-ro created clusterrole.rbac.authorization.k8s.io/all-rw created clusterrolebinding.rbac.authorization.k8s.io/owner-binding created rolebinding.rbac.authorization.k8s.io/auditor-binding created

Haz clic en Revisar mi progreso para verificar el objetivo. Crear las reglas de RBAC

Administra los recursos como propietario

1. En la parte superior de la ventana de terminal, haz clic en + para abrir una terminal nueva de Cloud Shell.

A continuación, establecerás una conexión SSH a la instancia de propietario y crearás una implementación simple en cada espacio de nombres.

2. Establece una conexión SSH a la instancia de propietario:

gcloud compute ssh gke-tutorial-owner Nota: Ignora el error relacionado con el complemento de autenticación de GCP.

3. Cuando se te pregunte acerca de la zona, ingresa n para que se use la zona predeterminada.

4. Instala gke-gcloud-auth-plugin:

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin echo "export USE_GKE_GCLOUD_AUTH_PLUGIN=True" >> ~/.bashrc source ~/.bashrc gcloud container clusters get-credentials rbac-demo-cluster --zone {{{project_0.default_zone|ZONE}}}

5. Crea un servidor en cada espacio de nombres; primero, en dev:

kubectl create -n dev -f ./manifests/hello-server.yaml

Resultado:

service/hello-server created deployment.apps/hello-server created

6. Luego, crea un servidor en prod:

kubectl create -n prod -f ./manifests/hello-server.yaml

Resultado:

service/hello-server created deployment.apps/hello-server created

7. Por último, crea un servidor en el espacio de nombres test:

kubectl create -n test -f ./manifests/hello-server.yaml

Resultado:

service/hello-server created deployment.apps/hello-server created

Haz clic en Revisar mi progreso para verificar el objetivo. Crear un servidor en cada espacio de nombres

Como propietario, también podrás ver todos los Pods.

• En la instancia de propietario, ejecuta el siguiente comando para enumerar los Pods hello-server en todos los espacios de nombres:

kubectl get pods -l app=hello-server --all-namespaces

Resultado:

NAMESPACE NAME READY STATUS RESTARTS AGE dev hello-server-6c6fd59cc9-h6zg9 1/1 Running 0 6m prod hello-server-6c6fd59cc9-mw2zt 1/1 Running 0 44s test hello-server-6c6fd59cc9-sm6bs 1/1 Running 0 39s

Visualiza los recursos como auditor

Ahora, abrirás una terminal nueva, establecerás una conexión SSH a la instancia de auditor y, luego, intentarás visualizar todos los espacios de nombres.

1. En la parte superior de la ventana de terminal, haz clic en + para abrir una terminal nueva de Cloud Shell.

2. Establece una conexión SSH a la instancia de auditor:

gcloud compute ssh gke-tutorial-auditor Nota: Ignora el error relacionado con el complemento de autenticación de GCP.

3. Cuando se te pregunte acerca de la zona, ingresa n para que se use la zona predeterminada.

4. Instala gke-gcloud-auth-plugin:

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin echo "export USE_GKE_GCLOUD_AUTH_PLUGIN=True" >> ~/.bashrc source ~/.bashrc gcloud container clusters get-credentials rbac-demo-cluster --zone {{{project_0.default_zone|ZONE}}}

5. En la instancia de auditor, ejecuta el siguiente comando para enumerar los Pods hello-server en todos los espacios de nombres:

kubectl get pods -l app=hello-server --all-namespaces

Deberías ver un error como el siguiente:

Error from server (Forbidden): pods is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot list pods at the cluster scope: Required "container.pods.list" permission

El error indica que no tienes permisos suficientes. El rol de auditor se restringió al espacio de nombres de desarrollo y tiene acceso de solo lectura, por lo que deberás especificar el espacio de nombres cuando visualices los recursos.

Ahora intenta visualizar los Pods en el espacio de nombres de desarrollo.

6. En la instancia de auditor, ejecuta el siguiente comando:

kubectl get pods -l app=hello-server --namespace=dev

Resultado:

NAME READY STATUS RESTARTS AGE hello-server-6c6fd59cc9-h6zg9 1/1 Running 0 13m

7. Intenta visualizar los Pods en el espacio de nombres de prueba:

kubectl get pods -l app=hello-server --namespace=test

Resultado:

Error from server (Forbidden): pods is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot list pods in the namespace "test": Required "container.pods.list" permission.

8. Intenta visualizar los Pods en el espacio de nombres de producción:

kubectl get pods -l app=hello-server --namespace=prod

Resultado:

Error from server (Forbidden): pods is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot list pods in the namespace "prod": Required "container.pods.list" permission.

Por último, intenta crear y borrar una implementación en el espacio de nombres de desarrollo para verificar que el auditor tenga acceso de solo lectura.

9. En la instancia de auditor, intenta crear una implementación:

kubectl create -n dev -f manifests/hello-server.yaml

Resultado:

Error from server (Forbidden): error when creating "manifests/hello-server.yaml": services is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot create services in the namespace "dev": Required "container.services.create" permission. Error from server (Forbidden): error when creating "manifests/hello-server.yaml": deployments.extensions is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot create deployments.extensions in the namespace "dev": Required "container.deployments.create" permission.

10. En la instancia de auditor, intenta borrar la implementación:

kubectl delete deployment -n dev -l app=hello-server

Resultado:

Error from server (Forbidden): deployments.extensions "hello-server" is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot update deployments.extensions in the namespace "dev": Required "container.deployments.update" permission.

Tarea 3: Situación 2: Asignación de permisos de API a una aplicación de clúster

En esta situación, seguirás el proceso para implementar una aplicación que requiera acceso a la API de Kubernetes y configurarás las reglas de RBAC mientras solucionas problemas de algunos casos de uso comunes.

Implementa la aplicación de prueba

La aplicación de prueba se ejecutará como un solo Pod que recupera, de forma periódica, todos los Pods en el espacio de nombres predeterminado del servidor de API y, luego, aplica una etiqueta de marca de tiempo a cada uno.

1. Desde la instancia admin (este debería ser tu primer tab de Cloud Shell), implementa la aplicaciónpod-labeler. Con esta acción, también se implementará un objeto Role, ServiceAccount y RoleBinding en el Pod:

kubectl apply -f manifests/pod-labeler.yaml

Resultado:

role.rbac.authorization.k8s.io/pod-labeler created serviceaccount/pod-labeler created rolebinding.rbac.authorization.k8s.io/pod-labeler created deployment.apps/pod-labeler created

Haz clic en Revisar mi progreso para verificar el objetivo. Implementar la aplicación de muestra

Diagnostica una configuración incorrecta de RBAC

Ahora verifica el estado del Pod. Una vez que se haya creado el contenedor, verás un error. Inspecciona los eventos y registros de los Pods para investigar el error.

1. En la instancia admin verifica el estado de los pods:

kubectl get pods -l app=pod-labeler

Resultado:

NAME READY STATUS RESTARTS AGE pod-labeler-6d9757c488-tk6sp 0/1 Error 1 1m

2. En la instancia admin visualiza el flujo de eventos del pod ejecutando:

kubectl describe pod -l app=pod-labeler | tail -n 20

Deberías ver lo siguiente:

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 7m35s default-scheduler Successfully assigned default/pod-labeler-5b4bd6cf9-w66jd to gke-rbac-demo-cluster-default-pool-3d348201-x0pk Normal Pulling 7m34s kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk pulling image "gcr.io/pso-examples/pod-labeler:0.1.5" Normal Pulled 6m56s kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Successfully pulled image "gcr.io/pso-examples/pod-labeler:0.1.5" Normal Created 5m29s (x5 over 6m56s) kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Created container Normal Pulled 5m29s (x4 over 6m54s) kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Container image "gcr.io/pso-examples/pod-labeler:0.1.5" already present on machine Normal Started 5m28s (x5 over 6m56s) kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Started container Warning BackOff 2m25s (x23 over 6m52s) kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Back-off restarting failed container

3. En la instancia admin ejecuta lo siguiente para verificar los registros del pod:

kubectl logs -l app=pod-labeler

Resultado:

Attempting to list pods Traceback (most recent call last): File "label_pods.py", line 13, in ret = v1.list_namespaced_pod("default",watch=False) File "build/bdist.linux-x86_64/egg/kubernetes/client/apis/core_v1_api.py", line 12310, in list_namespaced_pod File "build/bdist.linux-x86_64/egg/kubernetes/client/apis/core_v1_api.py", line 12413, in list_namespaced_pod_with_http_info File "build/bdist.linux-x86_64/egg/kubernetes/client/api_client.py", line 321, in call_api File "build/bdist.linux-x86_64/egg/kubernetes/client/api_client.py", line 155, in __call_api File "build/bdist.linux-x86_64/egg/kubernetes/client/api_client.py", line 342, in request File "build/bdist.linux-x86_64/egg/kubernetes/client/rest.py", line 231, in GET File "build/bdist.linux-x86_64/egg/kubernetes/client/rest.py", line 222, in request kubernetes.client.rest.ApiException: (403) Reason: Forbidden HTTP response headers: HTTPHeaderDict({'Date': 'Fri, 25 May 2018 15:33:15 GMT', 'Audit-Id': 'ae2a0d7c-2ab0-4f1f-bd0f-24107d3c144e', 'Content-Length': '307', 'Content-Type': 'application/json', 'X-Content-Type-Options': 'nosniff'}) HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"pods is forbidden: User \"system:serviceaccount:default:default\" cannot list pods in the namespace \"default\": Unknown user \"system:serviceaccount:default:default\"","reason":"Forbidden","details":{"kind":"pods"},"code":403}

Según este resultado, puedes ver un error de permisos cuando intentas enumerar los Pods a través de la API.

4. El siguiente paso consiste en confirmar que utilizas el objeto ServiceAccount correcto.

Corrige serviceAccountName

Al inspeccionar la configuración del Pod, puedes ver que usa el objeto ServiceAccount predeterminado en lugar del objeto ServiceAccount personalizado.

1. En la instancia admin ejecuta:

kubectl get pod -oyaml -l app=pod-labeler

Resultado:

restartPolicy: Always schedulerName: default-scheduler securityContext: fsGroup: 9999 runAsGroup: 9999 runAsUser: 9999 serviceAccount: default

El archivo pod-labeler-fix-1.yaml contiene la solución en la especificación de la plantilla de la implementación:

# Fix 1, set the serviceAccount so RBAC rules apply serviceAccount: pod-labeler

A continuación, aplicarás la solución y verás el cambio resultante.

2. En la instancia admin aplica la solución 1 ejecutando:

kubectl apply -f manifests/pod-labeler-fix-1.yaml

Resultado:

role.rbac.authorization.k8s.io/pod-labeler unchanged serviceaccount/pod-labeler unchanged rolebinding.rbac.authorization.k8s.io/pod-labeler unchanged deployment.apps/pod-labeler configured

3. Ve el cambio en la configuración de implementación:

kubectl get deployment pod-labeler -oyaml

Cambios en el resultado:

... restartPolicy: Always schedulerName: default-scheduler securityContext: {} serviceAccount: pod-labeler ...

Haz clic en Revisar mi progreso para verificar el objetivo. Corregir el nombre de la cuenta de servicio

Diagnostica privilegios insuficientes

Una vez más, verifica el estado de tu Pod y notarás que todavía tiene un error, pero esta vez el mensaje es diferente.

1. En la instancia admin, verifica el estado de tu pod:

kubectl get pods -l app=pod-labeler

Resultado:

NAME READY STATUS RESTARTS AGE pod-labeler-c7b4fd44d-mr8qh 0/1 CrashLoopBackOff 3 1m

Es posible que debas volver a ejecutar el comando anterior para ver este resultado.

2. En la instancia admin verifica los registros del pod:

kubectl logs -l app=pod-labeler

Resultado:

File "/usr/local/lib/python3.8/site-packages/kubernetes/client/rest.py", line 292, in PATCH return self.request("PATCH", url, File "/usr/local/lib/python3.8/site-packages/kubernetes/client/rest.py", line 231, in request raise ApiException(http_resp=r) kubernetes.client.rest.ApiException: (403) Reason: Forbidden HTTP response headers: HTTPHeaderDict({'Audit-Id': 'f6c67c34-171f-42f3-b1c9-833e00cedd5e', 'Content-Type': 'application/json', 'X-Content-Type-Options': 'nosniff', 'Date': 'Mon, 23 Mar 2020 16:35:18 GMT', 'Content-Length': '358'}) HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"pods \"pod-labeler-659c8c99d5-t96pw\" is forbidden: User \"system:serviceaccount:default:pod-labeler\" cannot patch resource \"pods\" in API group \"\" in the namespace \"default\"","reason":"Forbidden","details":{"name":"pod-labeler-659c8c99d5-t96pw","kind":"pods"},"code":403}

Dado que la falla se presenta en una operación de PATCH, también puedes ver el error en Stackdriver. Esto es útil si los registros de la aplicación no son lo suficientemente detallados.

3. En la consola, selecciona Menú de navegación y, en la sección Operaciones, haz clic en Logging.

4. En el cuadro de diálogo del Compilador de consultas, pega el siguiente código y haz clic en Ejecutar consulta (Run Query):

protoPayload.methodName="io.k8s.core.v1.pods.patch"

5. Haz clic en alguna flecha hacia abajo que se encuentre junto a un registro y explora los detalles.

Identifica el rol y los permisos de la aplicación

Usa el objeto ClusterRoleBinding para averiguar el rol y los permisos de ServiceAccount.

1. En la instancia admin inspecciona la definición del objeto rolebinding:

kubectl get rolebinding pod-labeler -oyaml

Resultado:

apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"name":"pod-labeler","namespace":"default"},"roleRef":{"apiGroup":"rbac.authorization.k8s.io","kind":"Role","name":"pod-labeler"},"subjects":[{"kind":"ServiceAccount","name":"pod-labeler"}]} creationTimestamp: "2020-03-23T16:29:05Z" name: pod-labeler namespace: default resourceVersion: "2886" selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/rolebindings/pod-labeler uid: 0e4d5be7-d986-40d0-af1d-a660f9aa4336 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pod-labeler subjects: - kind: ServiceAccount name: pod-labeler

El objeto RoleBinding muestra que debes inspeccionar el rol pod-labeler en el espacio de nombres predeterminado. Aquí, podrás ver que el rol solo tiene permiso para enumerar Pods.

2. En la instancia admin inspecciona la definición del rol pod-labeler:

kubectl get role pod-labeler -oyaml

Resultado:

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"pod-labeler","namespace":"default"},"rules":[{"apiGroups":[""],"resources":["pods"],"verbs":["list"]}]} creationTimestamp: "2020-03-23T16:29:05Z" name: pod-labeler namespace: default resourceVersion: "2883" selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/roles/pod-labeler uid: c8191869-c7de-42c6-98fc-79a91d9b02a1 rules: - apiGroups: - "" resources: - pods verbs: - list

Dado que la aplicación requiere permisos de PATCH, puedes agregarla a la lista de "verbos" del rol, y eso es lo que harás a continuación.

El archivo pod-labeler-fix-2.yaml contiene la solución en la sección de reglas y verbos:

rules: - apiGroups: [""] # "" refers to the core API group resources: ["pods"] verbs: ["list","patch"] # Fix 2: adding permission to patch (update) pods

Aplica la solución y verás la configuración resultante.

3. En la instancia de admin aplica fix-2:

kubectl apply -f manifests/pod-labeler-fix-2.yaml

Resultado:

role.rbac.authorization.k8s.io/pod-labeler configured serviceaccount/pod-labeler unchanged rolebinding.rbac.authorization.k8s.io/pod-labeler unchanged deployment.apps/pod-labeler unchanged

Haz clic en Revisar mi progreso para verificar el objetivo. Identificar el rol y los permisos de la aplicación

4. En la instancia de admin visualiza el cambio resultante:

kubectl get role pod-labeler -oyaml

Resultado:

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"pod-labeler","namespace":"default"},"rules":[{"apiGroups":[""],"resources":["pods"],"verbs":["list","patch"]}]} creationTimestamp: "2020-03-23T16:29:05Z" name: pod-labeler namespace: default resourceVersion: "8802" selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/roles/pod-labeler uid: c8191869-c7de-42c6-98fc-79a91d9b02a1 rules: - apiGroups: - "" resources: - pods verbs: - list - patch

Dado que pod-labeler puede estar en un bucle de retroceso, la forma más rápida de probar la solución es eliminar el Pod existente y dejar que uno nuevo ocupe su lugar.

5. En la instancia de administrador, ejecuta el siguiente comando para eliminar el Pod existente y dejar que el controlador de implementación lo reemplace:

kubectl delete pod -l app=pod-labeler

Resultado:

pod "pod-labeler-659c8c99d5-t96pw" deleted

Verifica si se realizó correctamente la configuración

Por último, verifica que se esté ejecutando el pod-labeler nuevo y que se haya aplicado la etiqueta "updated".

1. En la instancia de admin enumera todos los Pods y muestra sus etiquetas:

kubectl get pods --show-labels

Resultado:

NAME READY STATUS RESTARTS NAME READY STATUS RESTARTS AGE LABELS pod-labeler-659c8c99d5-5qsmw 1/1 Running 0 31s app=pod-labeler,pod-template-hash=659c8c99d5,updated=1584982487.6428008

2. Consulta los registros del Pod para verificar que ya no haya errores:

kubectl logs -l app=pod-labeler

Resultado:

Attempting to list pods labeling pod pod-labeler-659c8c99d5-5qsmw labeling pod pod-labeler-659c8c99d5-t96pw ...

Conclusiones principales

• Los registros del servidor de la API y de los contenedores son la mejor fuente de información para diagnosticar problemas de RBAC.
• Usa objetos RoleBinding o ClusterRoleBinding para determinar qué rol especifica los permisos para un Pod.
• Los registros del servidor de la API se pueden encontrar en Stackdriver, en el recurso Kubernetes.
• No todas las llamadas a la API se registrarán en Stackdriver. La política de auditoría de Kubernetes que usa Kubernetes Engine omite las cargas útiles frecuentes o detalladas. La política exacta variará según la versión de Kubernetes, pero se puede encontrar en la base de código abierto.

¡Felicitaciones!

Exploraste el control de acceso basado en roles (RBAC): asignaste diferentes permisos a diferentes usuarios arquetipo y otorgaste acceso limitado a la API a una aplicación que se ejecuta en tu clúster.

Próximos pasos y más información

• Configura el control de acceso basado en roles
• Crea políticas de IAM
• Autenticación de la cuenta de servicio de Kubernetes
• Documentación de Terraform

Capacitación y certificación de Google Cloud

Recibe la formación que necesitas para aprovechar al máximo las tecnologías de Google Cloud. Nuestras clases incluyen habilidades técnicas y recomendaciones para ayudarte a avanzar rápidamente y a seguir aprendiendo. Para que puedas realizar nuestros cursos cuando más te convenga, ofrecemos distintos tipos de capacitación de nivel básico a avanzado: a pedido, presenciales y virtuales. Las certificaciones te ayudan a validar y demostrar tus habilidades y tu conocimiento técnico respecto a las tecnologías de Google Cloud.

Última actualización del manual: 24 de febrero de 2025

Prueba más reciente del lab: 24 de febrero de 2025

Copyright 2024 Google LLC. Este software se proporciona tal como está, sin garantías ni declaraciones para ningún uso o propósito. El uso que hagas de él está sujeto a tu acuerdo con Google.