Permisos del controlador de sincronización

5 tareas · 40 min · Principiante

El controlador que sincroniza el repositorio con el clúster suele tener, por defecto, más permisos de los que necesita cualquiera de sus aplicaciones. Hay dos puertas que mirar: qué puede hacer cada persona a través de él y con qué cuenta aplica los cambios. En Cerámicas Albarracín, una empresa ficticia, el controlador de aplicaciones es Argo CD y el de la plataforma es Flux. Lees su política de acceso, sus proyectos y las cuentas con las que trabajan. Es lectura de configuraciones ficticias; no se ejecuta nada.

0 de 5 · 0%

Objetivo de la sala

Un controlador GitOps tiene permisos en dos planos distintos. El primero es el de sus usuarios: en Argo CD, una política de acceso (policy.csv) dice qué grupos pueden ver, sincronizar o borrar qué aplicaciones, y los proyectos (AppProject) limitan desde qué repositorios y hacia qué destinos puede desplegar cada una. El segundo es el de su cuenta en el clúster: lo que el propio controlador puede crear o borrar, que es lo que heredan sus aplicaciones.

Si el controlador tiene el rol de administrador del clúster, cualquier cosa que consiga desplegar tiene ese alcance, aunque el dueño de la aplicación sea un equipo pequeño.

Responde para continuar

Un controlador de sincronización tiene el rol de administrador de todo el clúster. ¿Qué implica para una aplicación que despliega?

Que sus manifiestos pueden crear o cambiar recursos con ese alcance, aunque solo necesite un espacio Que la aplicación queda limitada automáticamente a su propio espacio de nombres por el hecho de usar el controlador Que el rol solo se usa para leer el estado y los cambios los hace siempre la cuenta de cada persona

Ver pista de ayuda

Un manifiesto se aplica con los permisos de quien lo aplica.

En Flux, cada Kustomization puede declarar con qué cuenta de servicio se reconcilia (spec.serviceAccountName). Con ella, el controlador suplanta esa cuenta y solo puede hacer lo que sus permisos le dejan. Sin ella, aplica con la cuenta del propio controlador.

Abre flux-kustomizations.txt y cuentas-del-controlador.txt. Una de las cuatro Kustomizations de la plataforma no declara cuenta, de modo que se reconcilia con el rol de administrador del clúster.

Responde para continuar

Escribe el nombre de la Kustomization que se reconcilia sin serviceAccountName.

Ver pista de ayuda

Busca la fila con la columna de la cuenta vacía.

La política de acceso tiene cuatro roles. Uno es el de administración, que puede todo y se espera así. Pero otro rol, destinado a un equipo de aplicación, concede todas las acciones sobre aplicaciones de cualquier proyecto: no solo verlas o sincronizarlas, también borrarlas o cambiar sus parámetros. Compara las acciones y los objetos de cada línea p.

Responde para continuar

¿Qué rol, sin ser el de administración, concede todas las acciones sobre las aplicaciones de todos los proyectos? Escribe su nombre sin el prefijo role:.

Ver pista de ayuda

Busca el comodín en la columna de la acción y en la del objeto en un rol que no sea el de la plataforma.

Un proyecto es la frontera de despliegue: delimita de dónde puede venir el código y adónde puede ir. Un proyecto cuyos repositorios de origen sean * acepta cualquier repositorio, también uno que no controle la empresa. El proyecto default existe siempre y suele quedar abierto si nadie lo cierra.

Revisa proyectos.txt y cuenta los proyectos cuyo origen es literalmente *.

Responde para continuar

¿Cuántos proyectos aceptan cualquier repositorio de origen (origen *)?

Ver pista de ayuda

Cuenta solo las filas cuyo origen es el comodín completo, no un patrón con prefijo.

La auditoría ha encontrado tres cosas: una reconciliación sin cuenta propia, un rol de aplicación con alcance total y proyectos abiertos. Las tres se corrigen, pero cada una tiene un coste de cambio distinto. Se busca la corrección que reduzca más el alcance de un error o una intrusión con el menor riesgo de romper entregas.

Responde para continuar

¿Qué corrección reduce más el alcance de un manifiesto malicioso con poco riesgo de romper entregas?

Asignar cuenta propia con permisos mínimos a cada reconciliación y cerrar los proyectos abiertos Quitar al equipo de aplicación el permiso de ver sus propias aplicaciones en el controlador Cambiar el nombre de las aplicaciones para que sea más difícil localizarlas desde el controlador

Ver pista de ayuda

Reducir el alcance de la cuenta que aplica el cambio es lo que limita el daño.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 Dos puertas, dos listas de permisos

2 La reconciliación sin cuenta propia Lab

3 El rol que puede casi todo Lab

4 Los proyectos sin frontera Lab

5 Dónde se ajusta primero

Whoami-Labs Pro utiliza cookies