colorado - La relación entre puntos finales, regiones, etc. en KeyStack OpenStack
keystone colorado (4)
Intentaré poner esto en el lenguaje del laico.
Servicio: Openstack necesita una gran cantidad de servicios para que la infraestructura de la nube (Compute, Storage and Network) funcione. Para habilitarlos sin problemas al mismo tiempo para tener un control detallado, Openstack utiliza la noción de servicios. Los servicios permiten a los usuarios finales manipular uno de estos 3 recursos principales. Por ejemplo: para almacenamiento, se utilizan los servicios de Cinder y Swift. Estos servicios pueden configurarse para usar Ceph o gluster en el backend.
Punto final: el punto en el que ''ingresas'' a un servicio de pila abierta para hacer algo útil o destructivo. Es posible que se esté ejecutando un servicio, pero para ''entrar'' se necesita un punto final, que se verá como http://my-fancy-IP:hard-to-remember-port-number/v3.0 . Entonces, ¿no se han creado puntos finales en el sistema Openstack para un servicio en particular? No es posible acceder a ese servicio.
Región - Nada que ver con la geografía o la ubicación. Un término usado para dividir / agrupar implementaciones de openstack completo, si tiene muchas de ellas. La división puede basarse en la ubicación de los servidores físicos.
Usuario: usuario final o usted.
Proyecto / Arrendatario: un contenedor para separar sus recursos (cómputo, red de almacenamiento)
Dominio - Grupo de proyectos, grupos y usuarios. Proporciona separación de recursos para los usuarios y puede acomodar múltiples proyectos. Un usuario con rol de administrador de dominio puede crear / eliminar / actualizar cualquier proyecto, usuarios, grupos, etc. en ese dominio en particular.
Rol - Sus derechos para realizar cualquier operación en servicios de openstack. Piensa en el rol, piensa en el usuario.
Token: es un ID (una cadena larga) que te da Keystone. Puede acceder a cualquier servicio de OpenStack de acuerdo con el rol que se le asignó al usar este token.
Por ejemplo, puede solicitar nova y decir, hey nova, obtuve el token1 de keystone. Quiero eliminar el servidor "no me borres nunca". Nova toma el token1 y dice, oye Keystone, este usuario tiene el token1 y quiere eliminar el servidor ''no se borra nunca''. Keystone, mira el token1 y, de acuerdo con el rol asignado al usuario, dirá, ok nova permite / no permite que el usuario elimine el servidor ''no se elimine nunca''.
Realmente estoy tratando de entender lo que está debajo del capó de la clave sobre las relaciones entre los puntos finales, las regiones, los inquilinos, los servicios, los usuarios y los roles. He tratado de encontrar los documentos relacionados, pero lamentablemente, ha fallado.
¿Alguien podría dar alguna sugerencia o explicación?
Keystone es el servicio de gestión de identidad para OpenStack.
Esencialmente, su función es otorgar tokens a los usuarios, ya sean personas, servicios o cualquier otra cosa.
Si realiza una consulta de API en cualquier lugar de OpenStack, la API de Keystone es la forma en que se descubre si se le permite hacer esa consulta de API.
Vamos a trabajar nuestro camino desde el suelo.
Usuarios Los usuarios en Keystone hoy son generalmente personas. No hay suficiente soporte de ACL en este momento para llamar realmente a muchos de los usuarios de OpenStack una cuenta de ''servicio'' en un sentido tradicional. Pero hay una cuenta de servicio que se utiliza como conexión de retorno a la API de Keystone como parte de la infraestructura de OpenStack. Evitaremos ahondar en ese usuario anómalo.
Cuando un usuario se autentica en Keystone (pulsas el OS_AUTH_URL para hablar con Keystone ... normalmente el puerto 5000 del cuadro de api de Keystone), el usuario dice: "Soy el usuario X, tengo la contraseña Y y pertenezco al arrendatario Z". .
X puede ser un nombre de usuario o un ID de usuario (uuid exclusivo del usuario) Y es una contraseña, pero también puede autenticarse con un token. Z es el nombre del inquilino o la identificación del inquilino (uuid exclusivo del inquilino). en las API de Keystone anteriores, NO NECESITAS especificar el nombre de un inquilino, pero tu token no sería muy útil si no lo hicieras, ya que el token no estaría asociado con tu inquilino y se te denegará cualquier ACL en eso inquilino.
Entonces ... un usuario es algo bastante obvio. Una contraseña es algo bastante obvio. Pero ¿qué es un inquilino?
Bueno, un inquilino también es conocido como un proyecto. De hecho, ha habido intentos repetidos de hacer que el nombre sea un arrendatario o un proyecto, pero como resultado de la incapacidad de atenerse a un solo término, ambos significan lo mismo. En lo que respecta a la API, un proyecto es un inquilino. Así que si inicia sesión en el horizonte verá un menú desplegable para sus proyectos. Cada proyecto corresponde a una identificación del inquilino. Sus tokens están asociados con una identificación específica del inquilino también. Por lo tanto, es posible que necesite varios tokens para un usuario si desea trabajar con varios inquilinos a los que el usuario está vinculado.
Ahora, digamos que agrega un usuario a la identificación del inquilino de admin. ¿Tiene ese usuario privilegios de administrador? La respuesta es no. Ahí es donde los roles entran en juego. Mientras que el usuario en el administrador del inquilino puede tener acceso a las máquinas virtuales de administración y las cuotas para activar las máquinas virtuales, el usuario no podría hacer cosas como la clave de consulta para una lista de usuarios. Pero si agrega un rol de administrador a ese usuario, se le otorgarán los derechos de ACL para que actúen como un administrador en la API de Keystone y otras API. Así que piense en un inquilino como una especie de grupo de recursos y roles como un conjunto de ACL.
las regiones son más parecidas a formas de agrupar geográficamente los recursos físicos en el entorno de infraestructura de openstack. Digamos que tienes dos centros de datos segmentados. puede colocar uno en la región A de su entorno de openstack y otro en la región B. Las regiones en términos de su utilidad están evolucionando rápidamente, especialmente con la introducción de celdas y dominios en las versiones más recientes de openstack. Es probable que no necesite ser un maestro de este conocimiento a menos que tenga la intención de diseñar grandes nubes.
Keystone proporciona una última cosa útil. el catalogo El catálogo de Keystone es algo así como la guía telefónica para las APIs de OpenStack. siempre que use un cliente de línea de comandos, como cuando debería llamar a nova list para enumerar sus instancias, nova primero se autentica en Keystone y le da un token para usar la API, pero también le pide de inmediato al catálogo de Keystone una lista de puntos finales de API. Para Keystone, Cinder, Nova, Eight, Swift ... etc. Nova realmente solo usará el punto final nova-api, aunque dependiendo de su consulta, puede usar el punto final de la API administrativa de Keystone ... volveremos a eso . Pero, esencialmente, el catálogo es una fuente canónica de información sobre dónde se encuentran las API en el mundo. De esa manera, solo tendrá que decirle a un cliente dónde se encuentra el punto final de la API pública de Keystone, y puede descifrar el resto del catálogo.
Ahora, he hecho referencia a la API pública y a la API administrativa para la clave.
Yep keystone tiene dos API ... más o menos. Ejecuta una API en el puerto 5000 y otra en el rango de 32000. El 5000 es el puerto público. Aquí es donde haces cosas como buscar el catálogo y pedir un token para que puedas hablar con otras API. Es muy simple, y algo endurecido. La API administrativa se usaría para cosas como cambiar la contraseña de un usuario o agregar un nuevo rol a un usuario.
¿Muy claro?
Una respuesta tardía pero espero que sirva de ayuda a futuros lectores.
los puntos finales son como el punto de contacto para que usted use un servicio. adminurl como su nombre lo dice es solo para usuarios admin. la url interna es para que los distintos servicios se comuniquen entre sí si es necesario y la url pública es para que otra persona la use.
¿Por qué necesita una URL pública e interna separada?
No es necesario asignar una función para los puntos finales de servicio. Asigna roles a los usuarios que acceden al servicio y this es como lo hace.
This es mi forma de entender el inquilino, usuario, rol, permiso en OpenStack Keystone. Puede que te resulte interesante también.