Openshift – Autorizaciones

de usuarios y quotas
Proveedores de identidad

- Son los encargados de proporcionar los sitemas de autenticación a la

plataforma.
- Proporcionan la forma de cotejar las credenciales proporcionadas para los
usuarios y determinar si son usuarios autorizados o no para el uso del sistema.
- Cada proveedor de identidad almacena los datos de una froma determinada
- Se proporcionan numerosas integraciones que permiten la integración con
distintas plataformas de terceros.
Autenticación
- Openshift ofrece numerosos medios de autenticación mediante proveedores de
identidad:

Htpasswd

Keystone

LDAP

Basic Authentication

Request Header

Github/Github Enterprise

Gitlab

Google

OpenID Connect
Ejemplo de uso de htpasswd - consola
- Creación de un fichero httpasswd con usuarios y sus credenciales

- Creación de un secreto en el cluster a partir del fichero anterior

- Deficinición de un proveedor de identidad a partir del secreto anterior:

- oc apply -f crd-ip.yaml
Actualizar usuarios autorizados en httpasswd
- Obtención del secreto:
- oc get secret htpass-secret -ojsonpath={.data.htpasswd} -n openshift-config | base64 -d > users.htpasswd
- Manipulación de los usuarios añadiendo o quitando usuarios:

Añadir:

htpasswd -bB users.htpasswd <username> <password>

Quitar:

htpasswd -D users.htpasswd <username>


Reemplazo del secreto con el nuevo contenido del fichero htpasswd:

oc create secret generic htpass-secret --from-file=htpasswd=users.htpasswd --dry-run -o yaml -n openshift-
config | oc replace -f -

Si se han eliminado usuarios también se han de eliminar los recursos del cluster asociados a los mismos
(usuario e identidad):

Borrado de recurso de usuario: oc delete user <username>

Borrado de recurso de Identidad: oc delete identity my_htpasswd_provider:<username>
Proveedores de identidad desde consola web
- Acceso mediante usuario con permisos de administración de cluster.
- Opción de menú Administration -> Cluster Settings. Pestaña “Configuration”.
Configuración de recurso Oauth.
Proveedores de identidad desde consola web (2)
- Se pueden añadir o borrar proveedores de identidad para el cluster.
- Así como su método de mapeo de identidades.
Gestión de permisos - RBAC
- Role Based Access Control o de sus siglas en inglés RBAC es el sistema por el cual se
determina si un usuario está autorizado o no a realizar una determinada operación en el
cluster, en función de sus roles asignados.
- Los administradores pueden gestionar los permisos de los usuarios sobre recursos del
cluster.
- Los desarrolladores pueden usar roles locales para determinar quien tiene permisos
sobre sus aplicaciones.
- La autorización está basada en el uso de 3 entidades en Openshift:

Reglas (Rules): Set de acciones permitidas sobre objetos concretos (ej: crear pods).

Roles: Colección de reglas.

Enlaces (Bindings): asociación de usuarios o grupos con un rol.
Niveles - RBAC
- Cluster:

Roles y enlaces aplicables a todos los proyectos (namespaces).

Un rol con alcance de cluster existe a lo largo de los objetos de todo el cluster.

Un enlace a nivel de cluster solo puede referenciar roles a nivel de cluster.
- Local:

Roles y enlaces que están asociados con un proyecto concreto (namespace).

Enlaces locales pueden referenciar indistintamente roles locales y roles de cluster.

- Este doble nivel de gestión de roles permite reutilizar las asignaciones de permisos a
nivel cluster y refinarlas a nivel de proyecto de ser necesario.
Roles por defecto
Grupos y cuentas de servicios

- Grupo:

Agregación de roles.
- Cuentas de servicio (Service Account):

Cuenta de openshift que permite a una aplicación interactuar con el API del cluster.

Se puede considerar una cuenta de aplicación/sistema en lugar de una cuenta de un
usuario nominal.

Cada cuenta de servicio tiene asociados por defecto dos grupos:

system:serviceaccounts: incluye todas las cuenta de servicio del sistema

system:serviceaccounts:<project>: incluye todas las cuentas de servicio del
seleccionado proyecto.
Gestionar cuentas de servicio

- Listar:

oc get sa
- Crear:

oc create sa <service_account_name>

- Fichero yaml descriptivo de dicho recurso:

Visión general autenticación Openshift
Gestión desde consola web
Cuotas

- Especifican la limitación de un recurso físico u objeto del cluster en un proyecto

(namespace).
- Modeladas por medio del recurso ‘ResourceQuota’
- Viabilidad de especificarlas para los siguientes elementos:

Elementos computaciones:

CPU

RAM

Almacenamiento:

Espacio consumido por tipo de almacenamiento

Objetos del cluster:

Número de elementos

Reṕlicas/pods

Solicitudes de volúmenes persistentes
Quotas – Recursos computacionales
Quotas – Recursos almacenamiento
Quotas – Límites de números de objetos
Quotas – Alcances de cuotas
Quotas – Alcances - BestEffort

- Aplicable solo a Pods.

Quotas – Alcances Terminating, NotTerminating, NotBestEffort

- Aplicables a:

Pods

Memory

requests.memory

limits.memory

Cpu

requests.cpu

limits.cpu

Ephemeral-storage

requests.ephemeral-storage

limits.ephemeral-storage
Quotas – Requests / Limits
- Cada cuota puede especificar valores asociados a:

Requests

Limits
- Si la cuota especifica restricciones en función de “requests” requerirá que
cada futura definición de contenedor haga referencia explícita a nivel
“request” de dichos recursos.
- Si la cuota especifica restricciones en función de “limits” requerirá que cada
futura definición de contenedor haga referencia explícita a nivel de límite de
uso de dichos recursos.
 Quotas – Definición de cuota
- Objetos Openshift
- Objetos generales (Kubernetes)

- Recursos computacionales
 Quotas – Definición de cuota
- Tipología NotTerminating
- Calidad de servicio BestEffort

- Tipología Terminating - Restricción de almacenamiento

Quotas – Definición de pod con requests/limits

- 1) El contenedor solicita un uso de 100m de CPU.

- 2) El contenedor solicita un uso de 200Mi de memoria
- 3) El contenedor solicita un uso de 1Gi de almacenamiento efímero.
- 4) El contenedor especifica un límite de 200m de CPU.
- 5) El contenedor especifica un límite de 400mi de memoria.
- 6) El contenedor especifica un límite de 2Gi de almacenamiento efímero.
Quotas – Pods y sus scopes o Qos
- BestEffort:

Pods que no tienes especificación de límites de consumo de recursos.
- Not Best Effort:

El pod tiene al menos definida una restricción de límite de recursos.
- Terminating:

Pods que tienen definida una condición de fin de vida, normalmente incluyen builds,
deployers o jobs.
- Not Terminating:

No tienen fin de vida determinado. Normalmente son los encargados de correr
aplicaciones.
Quotas – Gestión por el cluster
- Tras crear una restricción de cuota (Quota) el projecto restringe la capacidad de crear
- nuevos recursos que puedan violar la restricción impuesta por la cuota hasta que haya
- refrescado sus estadísticas de uso.
- Tras el refresco de estadísticas el proyecto (namespace) vuelve a permitir creaciones de
recursos potencialmente afectados.
- Cuando se solicita creacción de recursos, el cluster incrementa inmediatamente el uso
de la cuota.
- Cuando se elimina un recurso el estado de la cuota es calculado durante el siguiente
proceso de recálculo completo de cuotas para el proyecto.
- Si las acciones solicitadas al proyecto exceden alguna cuota, el cluster deniega la
acción solicitada.
Quotas – Interacción
- Listado:

oc get quota -n <proyecto>

- Detalles

oc describe quota <nombre> -n <proyecto>

- Creación:

oc apply -f definicion-quota.yaml

- Borrado:

oc delete -f definicion-quota.yaml
Rangos límite (Limit Ranges)
- Definido por el recurso “LimitRange” en el cluster.
- Especifica límites de recursos de computación al nivel de:

Pod

Contenedor

Imagen

Image stream

solicitud de volúmen persistente
- Determina por tanto la cantidad de los recursos limitados que el recurso en concreto
puede consumir.
- Cada petición en el cluster de crear o modificar recursos, se evalua contra cada
LimitRange registrado en el proyecto (namespace). Si alguna no se cumple, la gestión
se rechaza.
- Si el recurso no especifica una definición por defecto y el LimitRange provee un valor
por defecto, este se estipula de manera automática.
- Los rangos límite son especificados por administradores del sistema y actúan a nivel de
proyecto.
Límites por rango - Ejemplo
Límites por rango - Interacción

oc get limits


cc apply -f limite-por-rango.yaml


oc delete -f limitepor-rango.yaml
Ejercicio 1

- Explora la documentación oficial sobre todo el detalle teórico de cuotas y límites por
rango:

https://docs.openshift.com/online/pro/dev_guide/compute_resources.html#dev-compute
-resources
Ejercicio 2

- Explora las capacidades de creación de roles realizando la creación de un nuevo rol

local.
Ejercicio 3

- Explora las capacidades de creación de relaciones (bindings) realizando la creación de

un nuevo binding local a tu propio usuario.
Ejercicio 4

- Explora las capacidades de creación de cuentas de servicio, por medio de la creación de

una nueva cuenta.
- Explora por ejemplo la cuenta de servicio asociada a los pipelines, creada en los temas
anteriores o creala si no existe en tu cluster.
Ejercicio 5

- Obtén el listado de cuotas de tu proyecto.

- Crea una cuota en tu proyecto.
- Elimina la anterior cuota de tu proyecto.
Ejercicio 6

- Obtén el listado de los límite por rango de tu proyecto.

- Crea un límite por rango en tu proyecto.
- Elimina el anterior límite por rango.