Hashicorp’s Vault

Requisitos previos Crear compañía Direcciones de correo electrónico y nombres de los usuarios que se agregarán. La persona que se agregará se registrará primero. Esto se hará en una reunión.

Applicación
Crear una aplicación en el Panel de Gestión

En la sección “Aplicaciones” puede ver todos los servicios protegidos que se han añadido a Ironchip y sus características. Para añadir un servicio, haga clic en “Nueva aplicación”, lo que abrirá una nueva ventana.

En la nueva ventana tendrá que elegir el nuevo servicio, en ese caso haga clic en “Aplicación personalizada”. Los parámetros para la nueva aplicación son

Nombre de la aplicación

Tipo de integración: OIDC - OAUTH 2.0

URIs de redirección:

http://<your service host>:8250/oidc/callback

http://<your service host>:8200/ui/vault/auth/oidc/oidc/callback

Una vez rellenados todos los campos, haga clic en “Añadir servicio” y el servicio aparecerá en la sección correspondiente.

Es importante guardar los campos que se devuelven al crear un servicio. Sólo aparecerán esta vez.

Configuración
Configuración de OIDC

Una vez dentro en la pestaña de acceso crear un nuevo método de autenticación oidc.

Para habilitar este método, introduzca la ruta oidc y habilite List method when unauthenticated. Seleccione el botón de habilitar el método.

Para la configuración de OIDC rellene los huecos con los siguientes parámetros:

OIDC discovery url : https://idp.ironchip.com/oidc

Default role : demo

OIDC response mode : query

OIDC client ID : El ID de cliente devuelto al crear la aplicación en el panel de control de Ironchip.

OIDC client secret : El secreto del cliente devuelto al crear la aplicación en el tablero de mandos de Ironchip.

Seleccione guardar. Puede ver cómo se ha creado el nuevo método de autenticación oidc.

Políticas

En la pestaña de políticas, si no hay ninguna política definida por defecto, créela con el siguiente contenido:
# Allow tokens to look up their own properties
path "auth/token/lookup-self" {
    capabilities = ["read"]
}

# Allow tokens to renew themselves
path "auth/token/renew-self" {
    capabilities = ["update"]
}

# Allow tokens to revoke themselves
path "auth/token/revoke-self" {
    capabilities = ["update"]
}

# Allow a token to look up its own capabilities on a path
path "sys/capabilities-self" {
    capabilities = ["update"]
}

# Allow a token to look up its own entity by id or name
path "identity/entity/id/" {
  capabilities = ["read"]
}
path "identity/entity/name/" {
  capabilities = ["read"]
}

# Allow a token to look up its resultant ACL from all policies. This is useful
# for UIs. It is an internal path because the format may change at any time
# based on how the internal ACL features and capabilities change.
path "sys/internal/ui/resultant-acl" {
    capabilities = ["read"]
}

# Allow a token to renew a lease via lease_id in the request body; old path for
# old clients, new path for newer
path "sys/renew" {
    capabilities = ["update"]
}
path "sys/leases/renew" {
    capabilities = ["update"]
}

# Allow looking up lease properties. This requires knowing the lease ID ahead
# of time and does not divulge any sensitive information.
path "sys/leases/lookup" {
    capabilities = ["update"]
}

# Allow a token to manage its own cubbyhole
path "cubbyhole/*" {
    capabilities = ["create", "read", "update", "delete", "list"]
}

# Allow a token to wrap arbitrary values in a response-wrapping token
path "sys/wrapping/wrap" {
    capabilities = ["update"]
}

# Allow a token to look up the creation time and TTL of a given
# response-wrapping token
path "sys/wrapping/lookup" {
    capabilities = ["update"]
}

# Allow a token to unwrap a response-wrapping token. This is a convenience to
# avoid client token swapping since this is also part of the response wrapping
# policy.
path "sys/wrapping/unwrap" {
    capabilities = ["update"]
}

# Allow general purpose tools
path "sys/tools/hash" {
    capabilities = ["update"]
}
path "sys/tools/hash/*" {
    capabilities = ["update"]
}

# Allow checking the status of a Control Group request if the user has the
# accessor
path "sys/control-group/request" {
    capabilities = ["update"]
}

# Allow a token to make requests to the Authorization Endpoint for OIDC providers.
path "identity/oidc/provider/+/authorize" {
	capabilities = ["read", "update"]
}
Esta política es para usuarios ordinarios, que no tendrán acceso a la pestaña de políticas. Si desea configurar un usuario administrador, se creará una política con el siguiente contenido:
path "sys/health"
{
  capabilities = ["read", "sudo"]
}

path "sys/policies/acl"
{
  capabilities = ["list"]
}

path "sys/policies/acl/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

path "auth/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

path "sys/auth/*"
{
  capabilities = ["create", "update", "delete", "sudo"]
}

path "sys/auth"
{
  capabilities = ["read"]
}

path "secret/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

path "sys/mounts/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

path "sys/mounts"
{
  capabilities = ["read"]
}
Como las políticas han sido definidas crearemos un rol de acuerdo a lo anterior. Esto se hará a través del terminal habilitado en la aplicación Vault.

Para el usuario común se creará el rol DEMO con el siguiente comando (No olvide rellenar el Client id):
vault write auth/oidc/role/demo \
        bound_audiences="CLIENT_ID" \
        allowed_redirect_uris="http://<your service host>:8200/ui/vault/auth/oidc/oidc/callback" \
        allowed_redirect_uris="http://<your service host>:8250/oidc/callback" \
        user_claim="sub" \
        policies="default" \
        verbose_oidc_logging="true"
Para el administrador común se creará el rol ADMIN con el siguiente comando (No olvide rellenar el Client id):
vault write auth/oidc/role/admin \
        bound_audiences="CLIENT_ID" \
        allowed_redirect_uris="http://<your service host>:8200/ui/vault/auth/oidc/oidc/callback" \
        allowed_redirect_uris="http://<your service host>:8250/oidc/callback" \
        user_claim="sub" \
        policies="admin" \
        verbose_oidc_logging="true"
Es importante recordar que el usuario establecido por defecto en la configuración de oidc no necesita ser introducido en el inicio de sesión, pero en este caso para entrar como administrador sería necesario introducir el rol.