En este artículo, veremos cómo los usuarios que reciben el error deben iniciar sesión en el servidor sin autorización cuando se conectan a un servidor API de Amazon Elastic Kubernetes Service.
Aquí tenemos un clúster de Amazon EKS que fue creado inicialmente por un usuario. Solo el creador del clúster de Amazon EKS tiene permiso de maestro del sistema para acceder y comunicarse con el clúster a través de la línea de comandos de Kubectl.
Primero verifiquemos nuestro usuario de AWS Identity and Access Management. Esto lo podemos configurar en nuestro terminal. En la interfaz de línea de comandos de AWS, ejecutaremos el siguiente comando para mostrar el usuario actual que configuramos en nuestra máquina local para usar con el siguiente comando:
$ aws sts get-caller-identity
Como este usuario es el mismo creador del clúster, actualizaremos el archivo de configuración de Kube con el siguiente comando:
$ aws eks update-kubeconfig --name eks-cluster-name --region aws-region
El archivo de configuración resultante se crea en la ruta predeterminada de Kubeconfig (.kube/config) en su directorio de inicio. El archivo kubeconfig es una forma de organizar información sobre clústeres, usuarios, espacios de nombres y mecanismos de autenticación.
Por lo tanto, la herramienta de línea de comandos de Kubectl usa archivos Kubeconfig para encontrar la información que necesita sobre el clúster y comprender cómo comunicarse con el servidor API de ese clúster.
Ahora tenemos el Kubeconfig actualizado y somos el creador del clúster. Podemos ejecutar el comando Kubectl, como Kubectl get-service, como se muestra a continuación:
$ kubectl get svc
Sin embargo, si cambiamos el usuario a cualquier otro usuario o asumimos algún rol, no podemos comunicarnos con el clúster usando Kubectl.
Aquí es donde iniciamos sesión en una instancia de nube de computadora elástica de Amazon. Realizaremos sts para obtener la identidad de la persona que llama. Esto muestra el rol adjunto a la instancia.
Realizaremos un comando de actualización de Kubeconfig como lo hicimos antes y veremos si podemos comunicarnos con el clúster. Ahora aplicaremos el comando Kubectl. Este comando genera un error no autorizado porque el rol de IAM asociado a la instancia EC2 no tiene permisos.
Entonces, desde la ventana del creador del clúster, agregaremos permisos al rol de IAM. Esto permite que la instancia EC2 se comunique con el clúster mediante el comando Kubectl.
Primero, agregaremos el rol de IAM al mapa de configuración de AWS para el clúster usando el siguiente comando:
$ kubectl edit configmap aws-auth -n kube-system
En roles de mapa, agregaremos el rol y le daremos permiso de maestro del sistema. El grupo de maestros del sistema permite el acceso de superusuario para realizar cualquier acción en cualquier recurso. Guardaremos los cambios y volveremos a intentarlo desde la instancia EC2.
Tenga en cuenta que el grupo de maestros del sistema permite el acceso de superusuario para realizar cualquier acción en cualquier recurso. Si desea restringir el acceso para este usuario, debe crear un rol de Kubernetes y un enlace de rol para este usuario que esté asignado en el control de acceso basado en roles.
Publicación traducida automáticamente
Artículo escrito por ddeevviissaavviittaa y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA