Cuentas de servicio e identidad de cargas de trabajo
Aprenda cómo las Service Accounts proporcionan su propia identidad a los Pods, cómo funcionan sus tokens y cómo concederles acceso con el mínimo privilegio.
Cuentas de servicio e identidad de cargas de trabajo es una lección gratuita de DevOps Bootcamp en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de DevOps Bootcamp, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de DevOps Bootcamp incluye 4 lecciones en total.
Identidad para las cargas de trabajo
Los usuarios se autentican en Kubernetes, pero los Pods también necesitan una identidad para comunicarse de forma segura con el servidor de API. Esa identidad es una cuenta de servicio.
¿Qué es una ServiceAccount?
Una ServiceAccount es un objeto con ámbito de espacio de nombres que representa la identidad de una carga de trabajo. Cada Pod se ejecuta con una; si no especifica ninguna, se usa default.
apiVersion: v1
kind: ServiceAccount
metadata:
name: report-generator
namespace: analyticsAsignar una cuenta de servicio a un Pod
Establezca serviceAccountName en la especificación del Pod para ejecutarlo con una identidad específica.
apiVersion: v1
kind: Pod
metadata:
name: reporter
spec:
serviceAccountName: report-generator
containers:
- name: app
image: reporter:1.0El token montado
Kubernetes monta en el Pod un token JWT de corta duración para la ServiceAccount, que se utiliza para autenticar las llamadas a la API.
# inside the Pod
cat /var/run/secrets/kubernetes.io/serviceaccount/tokenPor qué es arriesgada la cuenta predeterminada
La ServiceAccount default es compartida por todos los Pods de un espacio de nombres. Concederle permisos expondría demasiado todos los recursos. Es preferible usar una cuenta dedicada para cada carga de trabajo.
Deshabilitar el montaje automático del token
Si un Pod nunca llama a la API, deshabilite el montaje del token para reducir la superficie de ataque.
apiVersion: v1
kind: Pod
metadata:
name: no-api-pod
spec:
automountServiceAccountToken: false
containers:
- name: app
image: myapp:1.0Conceder permisos con RBAC
Una cuenta de servicio no tiene ningún poder hasta que se vincula a un Role. El subject de RoleBinding es la cuenta de servicio.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: reporter-read
namespace: analytics
subjects:
- kind: ServiceAccount
name: report-generator
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioEl principio de privilegio mínimo en la práctica
- Una cuenta de servicio por carga de trabajo
- Conceda únicamente los verbos y recursos que realmente necesita
- Limite el alcance a un espacio de nombres con Role cuando sea posible, en lugar de usar ClusterRole
Tokens vinculados y proyectados
Los tokens modernos son proyectados y están vinculados a la vida útil del Pod, con una caducidad breve. Se rotan automáticamente, por lo que un token filtrado es mucho menos peligroso que los secretos antiguos de larga duración.
Identidad de cargas de trabajo en la nube
Las plataformas en la nube asignan una ServiceAccount de Kubernetes a una identidad de IAM en la nube (por ejemplo, IRSA en AWS o Workload Identity en GKE), de modo que los Pods acceden a los recursos de la nube sin almacenar credenciales estáticas.
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123:role/report-roleVerificar los permisos
Use kubectl auth can-i suplantando la identidad de la ServiceAccount para confirmar que tiene exactamente el acceso esperado.
kubectl auth can-i list pods \
--as=system:serviceaccount:analytics:report-generator \
-n analyticsComprobación rápida
Compruebe cuánto entiende sobre las cuentas de servicio.
Resumen
Ha aprendido que una ServiceAccount proporciona a un Pod su propia identidad, respaldada por tokens proyectados de corta duración. Aplique el principio de privilegio mínimo con una cuenta dedicada por carga de trabajo, conceda acceso mediante vinculaciones de RBAC, deshabilite los montajes de tokens cuando no se utilicen y asigne las cuentas a IAM en la nube para obtener acceso sin credenciales.
Preguntas frecuentes
¿La lección «Cuentas de servicio e identidad de cargas de trabajo» es gratis?
Sí — el texto completo de «Cuentas de servicio e identidad de cargas de trabajo» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de DevOps Bootcamp, actualiza a CoddyKit PRO. El curso de DevOps Bootcamp incluye 4 lecciones en total.
¿Qué aprenderé en «Cuentas de servicio e identidad de cargas de trabajo»?
Aprenda cómo las Service Accounts proporcionan su propia identidad a los Pods, cómo funcionan sus tokens y cómo concederles acceso con el mínimo privilegio. Practicas DevOps Bootcamp con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar DevOps Bootcamp?
No se requiere experiencia previa. DevOps Bootcamp en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.
¿Cuánto tiempo toma la lección «Cuentas de servicio e identidad de cargas de trabajo»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de DevOps Bootcamp?
Sí. Cada lección de DevOps Bootcamp incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Control de acceso basado en roles (RBAC)
- Network Policies para el aislamiento
- Estándares de seguridad de los Pods
- Cuentas de servicio e identidad de cargas de trabajo