Hay mucho que aprender y comprender acerca de la ejecución de la nube. Kubernetes lo facilita al ayudarlo a administrar su nube, y una de las tareas más importantes en la administración de un clúster de servicios en la nube es administrar sus contenedores y contenedores. OpenShift maneja muchas de las complejidades que tendría que configurar directamente con Kubernetes sin procesar, por lo que puede ayudarlo a evitar sentirse abrumado por estos detalles.
Pero como con cualquier cosa, incluso dentro del (idealmente) predecible ámbito de los contenedores, pueden surgir problemas. De manera predeterminada, cada pod usa la cuenta de servicio predeterminada, que brinda acceso solo para obtener información de la API. A veces, los pods no pueden ejecutarse con las restricciones de la cuenta de servicio predeterminada. Cuando esto sucede, es hora de conocer las Restricciones del Contexto de Seguridad (SCC).
Cuando desee que el pod se ejecute con un SCC diferente, debe crear un cuenta de servicio Tiene los permisos que desea que herede el pod. Una cuenta de servicio es similar a una cuenta de usuario, excepto que se usa para servicios y procesos, no para usuarios humanos.
[ Getting started with containers? Check out this no-cost course. Deploying containerized applications: A technical overview. ]
Para ver qué SCC necesita aplicar, puede usar oc Ordenar:
$ oc get pod podname -o yaml | oc adm policy scc-subject-review -f -
Asumiendo que su nube tiene usuarios fulano de tal y un usuario administrador del clúster vcirrus-consultingAmbas cuentas están configuradas para usar Proveedor de identidad HTPasswd:
$ oc login -u janedoe
Logged into " as "janedoe" using existing credentials.
usuario fulano de tal Ejecutar con derechos de usuario estándar:
$ oc get users
Error from server (Forbidden): users.user.openshift.io is forbidden: User "janedoe" cannot list resource "users" in API group "user.openshift.io" at the cluster scope
$ oc get nodes
Error from server (Forbidden): nodes is forbidden: User "janedoe" cannot list resource "nodes" in API group "" at the cluster scope
Este fulano de tal El usuario crea un scc-demo:
$ oc new-project scc-demo
Now using project "scc-demo" on server ".
usar new-app Ordenar:
$ oc new-app --name sccnginx --docker-image nginx
Flag --docker-image has been deprecated, Deprecated flag use --image
--> Found container image 670dcc8 (2 days old) from Docker Hub for "nginx"
* An image stream tag will be created as "sccnginx:latest" that will track this image
--> Creating resources ...
imagestream.image.openshift.io "sccnginx" created
deployment.apps "sccnginx" created
service "sccnginx" created
--> Success
Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
'oc expose service/sccnginx'
Run 'oc status' to view your app.
A continuación, verifique el estado del pod:
$ oc get pods
NAME READY STATUS [...]
sccnginx-77...kw 0/1 ContainerCreating...
[ Want to test your sysadmin skills? Take a skills assessment today. ]
Todo parecía estar bien al principio, pero luego el pod falló:
$ oc get pods
NAME READY STATUS RESTARTS AGE
sccnginx-77cd9bf654-4wgkw 0/1 CrashLoopBackOff 2 (21s ago) 82s
Consulte los registros para obtener sugerencias sobre por qué el pod no se está ejecutando. He agregado comentarios al código a continuación (## IMPORTANT) para llamar su atención sobre las líneas más importantes. Desafortunadamente, en la vida real, los archivos de registro no tienen las anotaciones que dirigen su atención al resultado más importante.
$ oc logs sccnginx-77cd9bf654-4wgkw
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: can not modify /etc/nginx/conf.d/default.conf (read-only file system?)
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
## IMPORTANT
/docker-entrypoint.sh: Configuration complete; ready for start up
2022/07/22 14:23:21 [warn] 1#1: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
2022/07/22 14:23:21 [emerg] 1#1: mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)
nginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)
El Pod encontró un error de permiso porque el usuario lo ejecutó sin suficientes permisos. Inicie sesión como usuario con la función de control de acceso basado en funciones (RBAC) del administrador de clústeres (vcirrus-consulting en este ejemplo):
$ oc login -u vcirrus-consulting
Logged into as "vcirrus-consulting" using existing credentials.
Using project "scc-demo".
[ Get this complimentary eBook from Red Hat: Managing your Kubernetes clusters for dummies. ]
Analice la configuración YAML del pod para determinar qué permisos de SCC se requieren para que se ejecute el pod:
$ oc get pod sccnginx-77cd9bf654-4wgkw -o yaml | \
oc adm policy scc-subject-review -f -
RESOURCE ALLOWED BY
Pod/sccnginx-77cd9bf654-4wgkw anyuid
Un pod de fuente a imagen (S2I) requiere acceso más allá del alcance de su contenedor, por lo que debe ejecutarlo una cuenta de servicio en lugar de un usuario humano. Crear una nueva cuenta de servicio:
$ oc create sa nginx-sa
serviceaccount/nginx-sa created
Conectar cuenta de servicio nginx-sa a SCC cualquier usuario Usar enlaces de roles:
$ oc adm policy add-scc-to-user anyuid -z nginx-sa
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "nginx-sa"
Ahora vuelva a iniciar sesión como usuario fulano de tal y confirma que puedes acceder scc-demo proyecto:
$ oc login -u janedoe
Logged into " as "janedoe" using existing credentials.
You have one project on this server: "scc-demo"
Using project "scc-demo".
enlazar cuenta de servicio nginx-sa a la vaina o sccnginx Implemente para permitir que se ejecute con sus nuevos permisos:
$ oc set sa deploy sccnginx nginx-sa
deployment.apps/sccnginx serviceaccount updated
Verifique que los cambios surtieron efecto y que su pod (que anteriormente falló debido al acceso de root) ahora usa cualquier usuario CCS:
$ oc get pods
NAME READY STATUS RESTARTS AGE
sccnginx-594899cc8-cz9tb 1/1 Running 0 12s
Puede verificar que el pod realmente esté usando cualquier usuario CCS y oc describe Ordenar:
$ oc describe pod sccnginx-594899cc8-cz9tb | grep scc
Name: sccnginx-594899cc8-cz9tb
Namespace: scc-demo
Labels:
deployment=sccnginx
openshift.io/scc: anyuid
[…]
Cuentas de servicio y SCC
Las cuentas de servicio y los SCC son formas importantes de administrar los permisos dentro de un clúster. OpenShift tiene muchas formas de consultar su proyecto y clúster en busca de recursos, así que familiarícese con los comandos y construcciones disponibles para usted. Mi artículo de seguimiento cubre el uso y la administración de cuentas de servicio y SCC con más detalle.
También puedes leer Documentación de OpenShift SCC Consulte las diferentes opciones de SCC que puede usar para controlar el contexto de SELinux de un contenedor, solicitar funciones adicionales de un contenedor, cambiar las ID de usuario y usar directorios de host como volúmenes.
