Introducción
Orchard Market necesita un pequeño panel de estado para sus aplicaciones de puestos y entregas. El programa del panel está preparado, pero su identidad actual de Kubernetes no puede leer sus Deployments. Dale al panel su propia identidad y solo los permisos necesarios para mostrar las réplicas deseadas, las réplicas disponibles y las imágenes de plantilla reales. Mantén fuera de su acceso el espacio de nombres del personal, los Secrets y los cambios en las cargas de trabajo.
Tu resultado será un panel utilizable y una descarga CSV, además de cuatro manifiestos guardados que describen su identidad, las concesiones de permisos en dos espacios de nombres y la selección de identidad de la carga de trabajo. El panel realiza solicitudes HTTPS reales al clúster preparado. No tiene datos estáticos correctos con los que sustituir un acceso fallido.
Debes conocer ya las rutas básicas del terminal, el formato YAML sencillo, los espacios de nombres, Pods, Deployments, Services y etiquetas. Este laboratorio explica ServiceAccounts, Roles, RoleBindings y el cliente proporcionado antes de utilizarlos. Están preparados un clúster real de Kubernetes de un solo nodo, el panel, datos sintéticos de aplicaciones y la herramienta de diagnóstico. No instalas el clúster, construyes una imagen, programas el cliente ni copias tokens. La duración es una estimación del autor que incluye la lectura y los errores habituales, no una medición del tiempo de finalización de principiantes.
Crea una identidad exclusiva para el panel
En este paso, leerás la identidad inicial real del panel y guardarás una ServiceAccount exclusiva sin concederle todavía acceso a las aplicaciones.
Empieza en la pestaña Board. Orchard Market debe mostrar A clear view of the working day., los grupos Market stalls y Market delivery, y Access denied · API 403 para ambos grupos. Este es el problema inicial esperado. El resultado completo mostrará catalogue con 2 réplicas deseadas y 2 disponibles, checkout con 1 y 1, pickup con 1 y 1, y receipts con 0 y 0. Los cuatro usan la imagen de plantilla preparada python:3.12-alpine. El archivo de recibos está escalado a cero de forma intencional.
Los tres campos principales responden a preguntas diferentes. Desired replicas es la cantidad declarada en un Deployment. Available replicas es el recuento del controlador después de que las réplicas estén listas y cumplan el tiempo mínimo de preparación. Template image es la imagen solicitada por la plantilla del Deployment; durante una actualización no demuestra que todos los Pods existentes ya usen esa imagen. Expande What these fields mean, léelo y vuelve a contraerlo. Son observaciones del controlador, no comprobaciones de funcionamiento ininterrumpido del sitio web del cliente.
Elige Access details. El valor Read as procede de la API e inicialmente termina en market-board:default. La tabla indica el alcance de permisos previsto; no afirma que ya se haya concedido acceso. Usa Back to status board y cambia a Workspace.
El terminal comienza en /home/labex/project/status-board. pwd muestra tu directorio de trabajo, ls enumera sus entradas y cd con una ruta absoluta te devuelve aquí si cambiaste de directorio:
pwd
ls
cd /home/labex/project/status-board
Espera ver scope.json, starter y tools. cat muestra el archivo de alcance preparado. Usa JSON (JavaScript Object Notation), un formato de texto de valores con nombre y listas, para registrar los espacios de nombres, la identidad y los nombres de aplicaciones reales:
cat scope.json
El panel se ejecuta en market-board, mientras sus datos de aplicaciones aprobados están en market-stalls y market-delivery. market-office está excluido. --context=labex-v135 selecciona el clúster preparado; -n selecciona un espacio de nombres. Las credenciales de operador existentes de Workspace pueden inspeccionar y configurar estos objetos del curso. No son las credenciales del panel. Inspecciona los Deployments de destino reales como ese operador:
kubectl --context=labex-v135 get deployments -n market-stalls
kubectl --context=labex-v135 get deployments -n market-delivery
Lee los nombres y los resultados de réplicas deseadas y disponibles, incluido el archivo de recibos con cero réplicas deseadas. Los objetos subyacentes existen aunque el panel no pueda leerlos. Tener éxito desde este terminal de operador no demuestra que un proceso dentro del Pod del panel tenga acceso.
Una ServiceAccount es una identidad de API de Kubernetes, limitada a un espacio de nombres, para una carga de trabajo; no es un usuario de Linux ni un visitante del navegador. El Deployment del panel preparado selecciona inicialmente la ServiceAccount default. describe presenta la configuración del objeto en secciones legibles:
kubectl --context=labex-v135 describe deployment status-board -n market-board
Busca en su plantilla de Pod la ServiceAccount seleccionada. Un Pod recibe una credencial proyectada para esa cuenta. El cliente preparado la lee internamente y valida el certificado del servidor de API usando la autoridad de certificación proporcionada; nunca muestra la credencial ni usa tu kubeconfig de operador. Configuras la identidad y los permisos en lugar de implementar el manejo de credenciales.
El ./tools/board-test proporcionado ejecuta ese cliente dentro del Pod actual del panel. El ./ inicial significa que la herramienta está en este directorio de trabajo. Su primer argumento selecciona una operación de diagnóstico enseñada. identity pregunta a la API cómo ha autenticado esta credencial real:
./tools/board-test identity
Espera que username sea system:serviceaccount:market-board:default, con el pod_uid actual. El valor 201 de http_status significa que la API respondió a esta revisión de identidad propia. La revisión no es un objeto persistente del clúster, no cambia permisos ni crea un Deployment. No se muestra ningún token. Un proceso de panel listo y una identidad confirmada aún pueden carecer de acceso a los datos de aplicaciones.
Crea tu directorio de versión. mkdir -p lo crea si es necesario y conserva un directorio existente. En el siguiente comando, > redirige la salida a tu archivo editable. El marcador YAML entre comillas mantiene el texto literal hasta el marcador final en una línea propia. Repetir el comando sobrescribe solo ese archivo de versión:
mkdir -p release
cat > release/identity.yaml <<'YAML'
apiVersion: v1
kind: ServiceAccount
metadata:
name: market-reader
namespace: market-board
YAML
Lee tu archivo y aplícalo. apply -f lee el manifiesto indicado y crea o actualiza su objeto:
cat release/identity.yaml
kubectl --context=labex-v135 apply -f release/identity.yaml
kubectl --context=labex-v135 get serviceaccount market-reader -n market-board
La identidad exclusiva ya existe. No se requiere automáticamente un Secret de token de larga duración: Kubernetes proyecta en un Pod una credencial vinculada cuando ese Pod usa la identidad. Crear esta ServiceAccount por sí solo no concede acceso a Deployments ni cambia la identidad del panel en ejecución. Mantén sin cambios la cuenta default original.
Si escribes mal una ruta, usa los pwd, ls y cd absoluto ya mostrados y repite la operación fallida. Ante un error YAML, lee tu archivo editable, compara la sangría con el ejemplo completo, vuelve a escribirlo y aplícalo de nuevo. Mantén sin cambios scope.json, el archivo inicial, las herramientas, los espacios de nombres, las aplicaciones y los datos originales. Solo editarás los manifiestos de versión indicados y sus objetos de identidad y RBAC con nombre, además de la ServiceAccount seleccionada en el Deployment del panel.
Conecta el primer espacio de nombres
En este paso, concederás dos operaciones de lectura en el espacio de nombres de puestos y después harás que un nuevo Pod del panel use realmente la identidad exclusiva.
Empieza en Workspace, en /home/labex/project/status-board. RBAC de Kubernetes significa control de acceso basado en roles. Un Role define permisos dentro de un espacio de nombres. Un RoleBinding conecta el Role de ese espacio de nombres con una identidad. Que los nombres coincidan no establece por sí solo esta conexión.
El panel necesita list para leer una colección de Deployments y get para abrir un Deployment individual. Los Deployments pertenecen al grupo de API apps; la regla usa apps, sin /v1. watch solicitaría un flujo de cambios, que este panel no usa. No se necesitan verbos de escritura ni acceso a Secrets. Mantén ambos verbos de lectura disponibles para todos los Deployments de cada espacio de nombres aprobado. Omite resourceNames, el campo opcional de regla que restringe el permiso a recursos con nombres concretos. El roleRef.apiGroup del binding identifica la API de RBAC, rbac.authorization.k8s.io; difiere del grupo apps que contiene los Deployments permitidos por el Role.
Guarda un Role y su binding en un manifiesto. El separador --- inicia un segundo documento YAML. El metadata.namespace del binding es donde se aplica el permiso, mientras subjects.namespace es donde existe la ServiceAccount. Aquí son diferentes de forma deliberada:
cat > release/first-access.yaml <<'YAML'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-reader
namespace: market-stalls
rules:
- apiGroups: [apps]
resources: [deployments]
verbs: [get, list]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: board-reader
namespace: market-stalls
subjects:
- kind: ServiceAccount
name: market-reader
namespace: market-board
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: deployment-reader
YAML
Lee y aplica ambos objetos y después inspecciona la conexión interpretada:
cat release/first-access.yaml
kubectl --context=labex-v135 apply -f release/first-access.yaml
kubectl --context=labex-v135 describe role deployment-reader -n market-stalls
kubectl --context=labex-v135 describe rolebinding board-reader -n market-stalls
Espera ver solo get y list para Deployments. Sigue roleRef hasta el Role en market-stalls, y el sujeto hasta market-reader en market-board. El binding no crea una segunda ServiceAccount en el espacio de nombres de destino.
El panel en ejecución todavía usa default. La operación list de la herramienta de diagnóstico solicita la colección real de Deployments usando la credencial actual de ese Pod. Una lectura prohibida devuelve http_status: 403 y un estado de salida del comando distinto de cero; es lo esperado antes de que cambies la identidad de la carga de trabajo:
./tools/board-test list market-stalls
El nuevo permiso pertenece a market-reader, no a default. No lo resuelvas concediendo acceso a la cuenta default. Selecciona la cuenta exclusiva en una copia guardada del Deployment del panel preparado.
Primero lee el archivo inicial completo. Contiene la imagen existente, la fuente montada, la comprobación de salud, el número de réplicas y otros ajustes que debes conservar:
cat starter/board.yaml
kubectl set serviceaccount cambia la identidad seleccionada. --local transforma este archivo de entrada sin aplicarlo al clúster. -f indica la entrada, -o yaml escribe un manifiesto YAML en la salida estándar y el > ya aprendido lo guarda como tu archivo de versión editable:
kubectl --context=labex-v135 set serviceaccount --local -f starter/board.yaml market-reader -o yaml > release/board.yaml
Lee el resultado y confirma que spec.template.spec.serviceAccountName es market-reader. Conserva todos los demás ajustes de aplicación:
cat release/board.yaml
kubectl --context=labex-v135 apply -f release/board.yaml
No se puede cambiar directamente la ServiceAccount de un Pod existente. Actualizar la plantilla de Pod del Deployment crea un nuevo Pod. rollout status espera a la nueva carga de trabajo; --timeout=120s limita la espera:
kubectl --context=labex-v135 rollout status deployment/status-board -n market-board --timeout=120s
kubectl --context=labex-v135 get pods -n market-board
Espera ver un Pod actual del panel listo. Es necesario sustituir este Pod del panel; los Pods de las aplicaciones de destino no se cambian. Vuelve a leer su identidad autenticada real:
./tools/board-test identity
Espera ver system:serviceaccount:market-board:market-reader y un pod_uid diferente del Pod original con identidad default. Esto confirma la credencial del proceso, en lugar de limitarse a evaluar una identidad suplantada.
Los resultados de colección y detalle de Deployments también incluyen generation, la versión del estado deseado del Deployment, y observed_generation, la última versión procesada por su controlador. La página de detalles los etiqueta como Deployment generation y Observed generation. Un controlador puede retrasarse brevemente respecto a un cambio deseado. Estos campos no cuentan solicitudes de clientes ni demuestran disponibilidad del sitio web.
Lee la colección de puestos y un Deployment individual. get recibe el espacio de nombres seguido del nombre del Deployment:
./tools/board-test list market-stalls
./tools/board-test get market-stalls catalogue
Espera ver http_status: 200, ambos Deployments originales de puestos en la colección y catalogue con 2 réplicas deseadas y 2 disponibles en el resultado individual. El uid identifica el objeto original; la imagen de plantilla sigue siendo python:3.12-alpine. Un Role de un espacio de nombres no se extiende al espacio de nombres de entregas:
./tools/board-test list market-delivery
Espera un 403 de la API y un estado del comando distinto de cero para este último comando. Cambia a Board, usa Refresh view, abre Inspect catalogue y lee sus cantidades deseadas y disponibles y Template image. Usa Back to status board. Las tarjetas de puestos deben funcionar mientras el grupo de entregas todavía muestra Access denied · API 403. Este resultado parcial es una evidencia útil del límite entre espacios de nombres.
Si Read as aún muestra la identidad anterior justo después de un despliegue, usa Refresh view de nuevo. Para confirmar el Pod actual, cambia a Workspace, repite ./tools/board-test identity y vuelve a Board para actualizar. El enrutamiento del Service puede necesitar un breve momento para reflejar el despliegue; no concedas acceso a la identidad antigua para ocultar la transición.
Compara el lector real, las tarjetas de puestos correctas y el grupo de entregas todavía denegado en este ejemplo en ejecución:
Si se agota el tiempo de espera del despliegue, vuelve a Workspace e inspecciona el mismo Deployment y sus Pods con los comandos describe y get ya mostrados. Si se deniega una lectura inesperadamente, compara el Role, el espacio de nombres del sujeto del RoleBinding y la identidad seleccionada de la carga de trabajo. Corrige solo tu archivo de versión, aplícalo y repite el despliegue o la solicitud correspondiente. No copies credenciales de operador, no cambies la aplicación ni reinicies la VM.
El roleRef de un RoleBinding es inmutable. Si un error anterior creó el nuevo binding board-reader de este curso con una referencia de Role incorrecta, Kubernetes rechazará cambiar esa referencia directamente. Tras inspeccionarlo y corregir release/first-access.yaml, recrea solo tu propio binding con ese nombre y aplica el archivo guardado corregido:
kubectl --context=labex-v135 delete rolebinding board-reader -n market-stalls
kubectl --context=labex-v135 apply -f release/first-access.yaml
Estos son comandos de recuperación condicional, no una eliminación requerida en la ruta normal de éxito. No elimines bindings default o de la plataforma ni elimines el Deployment original del panel o las cargas de trabajo de destino.
Amplía el panel sin ampliar su cometido
En este paso, concederás a la misma identidad las mismas dos operaciones de lectura en el espacio de nombres de entregas y después verificarás una salida útil y los límites protegidos.
Empieza en Workspace, en /home/labex/project/status-board. Un segundo espacio de nombres necesita su propio Role y RoleBinding. Reutiliza allí el nombre del Role, pero mantén el sujeto en market-board; la identidad no se ha movido:
cat > release/second-access.yaml <<'YAML'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-reader
namespace: market-delivery
rules:
- apiGroups: [apps]
resources: [deployments]
verbs: [get, list]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: board-reader
namespace: market-delivery
subjects:
- kind: ServiceAccount
name: market-reader
namespace: market-board
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: deployment-reader
YAML
cat release/second-access.yaml
kubectl --context=labex-v135 apply -f release/second-access.yaml
kubectl --context=labex-v135 describe rolebinding board-reader -n market-delivery
El binding concede este Role de destino a la identidad existente del panel. No se necesita otro despliegue del panel porque el Pod actual ya usa esa identidad. Los permisos de RBAC se suman; cambiar el orden de los archivos no introduce una regla de denegación ni elimina otra concesión de permisos.
Lee ambas colecciones aprobadas y un detalle de entregas mediante la credencial real del panel:
./tools/board-test list market-stalls
./tools/board-test list market-delivery
./tools/board-test get market-delivery pickup
Espera un 200 de la API con los objetos e imágenes originales. La colección de entregas incluye pickup con 1 réplica deseada y 1 disponible y receipts con 0/0. El Deployment con cero réplicas deseadas sigue siendo un objeto real aunque no tenga Pods en ejecución. Conserva este ajuste declarado.
Ahora comprueba los datos excluidos. Un Secret de Kubernetes almacena valores de datos con nombre. El staff-note preparado es un recurso sintético de prueba; el panel no tiene motivo para leerlo. El operador puede confirmar que este objeto existe sin mostrar sus valores:
kubectl --context=labex-v135 get secret staff-note -n market-stalls
La credencial propia del panel debe seguir recibiendo un 403 de la API para el tercer espacio de nombres y este Secret. Se espera que ambos comandos siguientes terminen con un estado distinto de cero:
./tools/board-test list market-office
./tools/board-test secret market-stalls staff-note
Un objeto que falta, un fallo de conexión o una captura de pantalla de un error no equivalen a este rechazo real de autorización. El mismo cliente lee correctamente los destinos aprobados mientras los objetos excluidos existentes permanecen intactos. Su archivo de credencial proyectada no le concede acceso a la API de Secrets.
La operación permission de la herramienta pregunta a la API si esta credencial real puede realizar una acción. No realiza esa acción. Los argumentos son el espacio de nombres, el verbo y, cuando corresponde, el nombre del Deployment. La revisión no persistente devuelve http_status: 201 con allowed: false para cada operación prohibida; la herramienta devuelve un estado distinto de cero por esa denegación:
./tools/board-test permission market-stalls patch catalogue
./tools/board-test permission market-delivery delete pickup
./tools/board-test permission market-stalls create
El panel solo necesita get y list; no se autoriza ningún flujo watch ni modificación de cargas de trabajo. Mantén sin cambios la identidad default y el RBAC original de la plataforma. No añadas un ClusterRole, ClusterRoleBinding, comodín, sujeto adicional ni permiso sobre otro recurso.
Cambia a Board y usa Refresh view. Ambos grupos muestran ahora sus Deployments originales. Abre Inspect pickup, lee sus cantidades e imagen y usa Back to status board. Lee la tarjeta receipts: Scaled to zero, 0 disponibles, 0 deseadas. No es un sustituto vacío para una solicitud fallida.
Compara el lector real, las cuatro tarjetas de Deployments y el archivo visible con cero réplicas deseadas en este ejemplo completo:
Elige Download CSV y abre el orchard-market-deployments.csv real descargado. Tiene cuatro filas de datos, una por cada Deployment original, incluido el archivo de recibos. Comprueba que el espacio de nombres, el nombre del Deployment, los valores deseados y disponibles, la imagen de plantilla y el estado de la API coincidan con la página. Es una exportación nueva de la API, no una muestra correcta guardada. Las descargas del navegador y el espacio de trabajo del terminal son ubicaciones separadas; no se te pide copiar la descarga al espacio de trabajo.
Elige Access details, confirma el valor real Read as y ambos alcances de espacios de nombres previstos y usa Back to status board. Conserva cada Deployment de destino original, las identidades de Pods y contenedores, la fuente, la imagen, los datos y las etiquetas de espacios de nombres. Conserva el Deployment y el Service originales del panel; solo cambia su ServiceAccount seleccionada. La versión reutilizable contiene identity.yaml, first-access.yaml, second-access.yaml y board.yaml, que coinciden con la identidad real y los permisos en servicio.
Si el segundo espacio de nombres sigue denegado, vuelve a Workspace, inspecciona su binding con el comando describe mostrado, compara el espacio de nombres del sujeto y la referencia de Role, corrige tu archivo guardado y aplícalo de nuevo. Ante un roleRef incorrecto inmutable, usa la misma recuperación restringida enseñada antes, ahora solo para tu nuevo binding de entregas:
kubectl --context=labex-v135 delete rolebinding board-reader -n market-delivery
kubectl --context=labex-v135 apply -f release/second-access.yaml
Ejecuta estos comandos solo para esa recuperación específica. Si el acceso excluido tiene éxito inesperadamente, inspecciona tus dos Roles guardados y sus bindings, elimina el permiso no previsto dentro de esos objetos y vuelve a aplicar. Un permiso amplio no queda anulado por otro Role más restringido. No edites permisos de la plataforma ni la aplicación para ocultar un error. Los errores de ruta y YAML usan la recuperación ya enseñada, sin restablecer la VM.
La herramienta terminada lee el estado de Deployments informado por el controlador en este clúster preparado de un solo nodo. No autentica visitantes del panel, no lee registros ni métricas de Pods ni demuestra un funcionamiento ininterrumpido en producción. Su punto de comprobación de preparación solo confirma que el proceso del panel puede servir; los resultados reales de la API establecen si se puede acceder a los datos de aplicaciones.
Resumen
Diste a un consumidor real dentro del clúster su propia ServiceAccount, conectaste un Role y un RoleBinding limitados a un espacio de nombres e hiciste que un nuevo Pod utilizara realmente esa identidad. Después ampliaste el mismo trabajo de lectura a un segundo espacio de nombres aprobado sin conceder acceso a datos excluidos ni a cambios en las cargas de trabajo.
El panel utilizable, el CSV actual y los manifiestos guardados relacionan la identidad, los permisos y la salida real de la API. Las réplicas deseadas, la disponibilidad informada por el controlador y las imágenes de plantilla siguen siendo observaciones distintas. Un rechazo de la API sigue mostrándose como no disponible, mientras un Deployment intencionalmente configurado con cero réplicas deseadas sigue visible como objeto real.
