El script automatiza el proceso completo de creación de un usuario en Kubernetes. Como el proceso es algo diferente en K3s, esta entrada se centra más en este caso especial.
ops
Photo by Mabel Amber
Crear usuarios en Kubernetes (y en K3s)
- post
- Xavi Aznar
En Kubernetes no existe el concepto de usuario; sólo se confía en quien presente un certificado firmado por la CA del clúster.
Para obtener los certificados de la CA, lo más sencillo es acceder a un nodo server; los certificados (
ca.cert
yca.key
) se encuentran en/etc/kubernetes/pki/
.Existe otra opción que pasa por generar un objeto
CertificateSigningRequest
para firmar el certificado de usuario.El proceso implica generar un certificado al usuario, solicitar que lo firme la Certificate Authority del clúster y después autenticarse con él.
Para poder autenticarse en el clúster, necesitamos configurar un cliente, por ejemplo creando un fichero
kubeconfig
para kubectl.Finalmente, el nuevo usuario debe estar autorizado a realizar algunas acciones en el clúster; para ello definiremos un conjunto de permisos en un Role o un ClusterRole y lo asociaremos al usuario mediante un RoleBinding (o un ClusterRoleBinding).
Uno de los problemas abiertos de Kubernetes es la gestión de los secretos; es decir, aquella información sensible que, al menos de momento, se guarda en texto plano y cuya única medida de “seguridad” consiste en codificarla en base64.
Tal y como se indica en el
README.md
de Sealed Secrets, puedes gestionar toda la configuración de Kubernetes en Git… excepto los Secrets, precisamente porque los Secrets no son seguros…Con el auge de metodologías como GitOps, el problema es mayor, ya que los desarrolladores no tienen acceso directo al clúster y todo debe desplegarse automáticamente desde Git.
Una de las soluciones al problema viene del equipo de Bitnami-Labs con SealedSecrets.
Actualiza la versión de Alpine Linux
- post
- Xavi Aznar
Hace unos días actualicé la versión de Pop_OS! en uno de los equipos de escritorio en los que tengo Linux instalado en casa.
Hoy estaba revisando las máquinas virtuales y mientras actualizaba los paquetes de una VM con Ubuntu 20.04 he pensado cómo podría actualizar de Alpine 3.13 a la última versión publicada, Alpine 3.14.
El proceso no puede ser más sencillo.
Velero realiza copias de seguridad (puntuales o recurrentes) para recuperarnos con rapidez de un desastre en el clúster de Kubernetes.
En la entrada anterior Velero - Backup y Disaster Recovery para Kubernetes (II) Crear copia de seguridad desplegamos una aplicación de prueba en el clúster (dos réplicas de Nginx en el Namespace
nginx-example
). Simulamos la pérdida “accidental” del Namespacenginx-example
para ver cómo recuperarnos usando la copia creada por Velero.En la entrada anterior Velero - Backup y Disaster Recovery para Kubernetes (I) Instalación vimos cómo instalar Velero en Kubernetes. Usamos el comando
velero install
lanzado desde un Job en la línea de la filosofía GitOps.En esta entrada veremos cómo crear copias de seguridad puntuales y recurrentes usando la herramienta de línea de comandos velero (lanzada desde un Job)
Velero es una herramienta de código abierto que permite realizar copias de seguridad, restaurarlas y migrar recursos de Kubernetes entre clústers (lo que también permite recuperar un clúster en caso de desastre).
Velero soporta diferentes proveedores en los que almacenar las copias de seguridad que realiza. La lista completa y actualizada se encuentra en Providers. En mi caso, voy a utilizar MinIO, que es compatible con AWS S3 y que tengo desplegado localmente en Kubernetes.
Eliminar namespace encallado en Terminating
- post
- Xavi Aznar
Al hacer limpieza de uno de los clústers de desarrollo, he borrado dos namespaces y los dos se han quedado en estado Terminating
Idealmente, el análisis de los ficheros de definición de objetos (YAML) en Kubernetes debería realizarse antes de crear los objetos en el clúster. Para ello, uno de los stages del proceso de CI/CD debería incorporar KubeLinter (por ejemplo).
De forma paralela, también deberíamos tener un proceso periódico que revise los ficheros de definición de los objetos que tenemos almacenados en el repositorio para identificar, por ejemplo, el uso de versiones de la API desaconsejadas (deprecated) en proceso de eliminación de la API.
En este artículo vemos cómo configurar un Cronjob que ejecute KubeLinter para obtener los ficheros de un repositorio remoto y analizarlos.