Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Ejemplo 1: ABAC básico con OPA y Rego

En esta sección se describe un escenario en el que la OPA se utiliza para tomar decisiones de acceso sobre qué usuarios pueden acceder a la información de un microservicio ficticio de nómina. Los fragmentos de código de Rego se proporcionan para demostrar cómo se puede utilizar Rego para tomar decisiones de control de acceso. Estos ejemplos no son exhaustivos ni una exploración completa de las capacidades de Rego y OPA. Para obtener una descripción más completa de Rego, le recomendamos que consulte la documentación de Rego en el sitio web de la OPA.

Ejemplo de reglas básicas de OPA

En el diagrama anterior, una de las reglas de control de acceso que la OPA aplica al microservicio de nóminas es:

Los empleados pueden leer su propio salario.

Si Bob intenta acceder al microservicio de nómina para ver su propio salario, el microservicio de nómina puede redirigir la llamada a la API a la RESTful API de OPA para tomar una decisión de acceso. El servicio de nómina consulta a la OPA para tomar una decisión con la siguiente entrada de JSON:

{
    "user": "bob",
    "method": "GET",
    "path": ["getSalary", "bob"]
}

La OPA selecciona una o varias políticas en función de la consulta. En este caso, la siguiente política, que está escrita en Rego, evalúa la entrada de JSON.

default allow = false
allow = true {
    input.method == "GET"
    input.path = ["getSalary", user]
    input.user == user
}

Esta política deniega el acceso de forma predeterminada. A continuación, evalúa la entrada de la consulta vinculándola a la variable input global. El operador de punto se usa con esta variable para acceder a los valores de la variable. La regla Rego allow devuelve el valor verdadero si las expresiones de la regla también lo son. La regla Rego verifica que la method entrada sea igual a GET. Luego verifica que el primer elemento de la lista path esté getSalary antes de asignar el segundo elemento de la lista a la variable. user Por último, comprueba que la ruta a la que se accede es /getSalary/bob comprobando que la variable que se está user realizando la solicitud coincide con la user variable. input.user La regla allow aplica la lógica if-then para devolver un valor booleano, como se muestra en el resultado:

{
    "allow": true
}

Regla parcial que utiliza datos externos

Para demostrar las capacidades adicionales de la OPA, puede añadir requisitos a la regla de acceso que está aplicando. Supongamos que desea hacer cumplir este requisito de control de acceso en el contexto de la ilustración anterior: 

Los empleados pueden leer el salario de cualquier persona que dependa de ellos.

En este ejemplo, OPA tiene acceso a datos externos que se pueden importar para tomar una decisión de acceso:

"managers": {
        "bob": ["dave", "john"],
        "carol": ["alice"]
}

Puede generar una respuesta JSON arbitraria creando una regla parcial en OPA, que devuelva un conjunto de valores en lugar de una respuesta fija. Este es un ejemplo de una regla parcial:

direct_report[user_ids] {
    user_ids = data.managers[input.user][_]
}

Esta regla devuelve un conjunto de todos los usuarios que informan con el valor deinput.user, que, en este caso, esbob. La [_] construcción de la regla se usa para recorrer en iteración los valores del conjunto. Este es el resultado de la regla:

{
    "direct_report": [
      "dave",
      "john"
    ]
}

La recuperación de esta información puede ayudar a determinar si un usuario depende directamente de un administrador. Para algunas aplicaciones, es preferible devolver un JSON dinámico a devolver una respuesta booleana simple.

Resumen global

El último requisito de acceso es más complejo que los dos primeros porque combina las condiciones especificadas en ambos requisitos:

Los empleados pueden leer su propio salario y el de cualquier persona que dependa de ellos.

Para cumplir con este requisito, puede utilizar esta política de Rego:

default allow = false
 
allow = true {
    input.method == "GET"
    input.path = ["getSalary", user]
    input.user == user
}
 
allow = true {
    input.method == "GET"
    input.path = ["getSalary", user]
    managers := data.managers[input.user][_]
    contains(managers, user)
}

La primera regla de la política permite el acceso a cualquier usuario que intente ver su propia información salarial, como se mencionó anteriormente. Al tener dos reglas con el mismo nombreallow, funciona como un lógico u operador en Rego. La segunda regla recupera la lista de todos los subordinados directos asociados input.user (a partir de los datos del diagrama anterior) y asigna esta lista a la variable. managers Por último, la regla comprueba si el usuario que está intentando ver su salario depende directamente de él, input.user comprobando que su nombre aparece en la variable. managers

Los ejemplos de esta sección son muy básicos y no proporcionan una exploración completa o exhaustiva de las capacidades de Rego y OPA. Para obtener más información, consulte la documentación de la OPA, consulte el archivo GitHub README de la OPA y experimente en el entorno de juegos de Rego.