We’re excited to share the latest product improvements and the implications for you, our end users. We have released a new version of the directory which supports ReBAC, and we’ve made several updates to our CLI to make it easier to interact with the authorizer and create policies for OpenAPI-based services. Additionally, decision logs can now be relayed from edge authorizers to the control plane.

The New Aserto Directory

Aserto allows you to combine the “policy-as-code” and “policy-as-data” approaches to support even the most complex and fine-grained authorization scenarios. Your policies will still encapsulate the logic of your authorization model in the form of Rego code. But now, Aserto’s new directory allows you to define your domain model to express different relationships within it. You can then leverage those relationships in the authorization decision process. Read more about the new Aserto Directory here.

CLI Improvements

Authorizer interaction

The latest release of the Aserto CLI (v0.8.19) lets you pass identity and resource contexts to the aserto authorizer [eval-decision|decision-tree|exec-query] commands. This means you can call your policy instances from the CLI in much the same way you use the console’s policy evaluator.

aserto authorizer eval-decision --tenant=<tenant-id> --policy-id=<policy-id> --path=<policy-path> --decisions=allowed \
 --identity=<account_id|identity|jwt> --identity-type=<sub|jwt|none> \
 --resource '{"key1": "val1", "key2": 2}'

We hope this makes interaction with the authorizer easier when using the CLI.

Policy Generation for OpenAPI services

If you’ve built your service in compliance with the OpenAPI spec, the Aserto CLI can now generate a policy for each one of your service routes automatically. To generate a policy, run the following command:

aserto developer (x) policy-from-open-api <url> [<name>]

The provided URL should point to your OpenAPI spec YAML file.

Decision Logs relayed from Edge Authorizers

Decision logs are critical for establishing a clear understanding of what authorization decisions were made by the hosted and edge authorizers. Until now, decision logs were only collected for the hosted authorizer. Starting with version 0.9.25, edge authorizers will now relay decision logs back to the control plane.

Using the latest version of the CLI (v0.8.19), generate the configuration for the edge authorizer, run:

aserto x configure --edge-authorizer=<edge connection id> --decision-logging

Note that the -–decision-logging option is only valid when the  --edge-authorizer option is also provided.

In order to guarantee delivery of every decision log, the edge authorizer requires persistent storage for in-flight logs. If you’re using the Onebox authorizer, use the new --data-path argument to specify the storage location:

aserto x start --data-path=<path> <policy-name>

Note that if the configuration for the policy doesn’t include decision logging, using the --data-path option will result in an error.

If you’re using the dockerized edge authorizer, you can mount the decision logs folder onto your container and then specify the mapped location in the config file. For example, when storing the decision logs in /app/decision_logs on the container, you’d start the container using this command:

#!/usr/bin/env bash
 
docker run \
-ti \
--rm \
--name aserto-one \
--platform=linux/amd64 \
-p 8282:8282 \
-p 8383:8383 \
-p 8484:8484 \
-v $PWD/certs:/certs:rw \
-v $PWD/cfg:/app/cfg:ro \
-v $PWD/eds:/app/db:rw \
-v $PWD/decision_logs:/app/decision_logs:rw
ghcr.io/aserto-dev/authorizer-sidecar:latest run \
--config-file /app/cfg/config.yaml

You’ll also have to point your configuration to point to this path, as shown in the following example:

---
logging:
  prod: true
  log_level: info

directory_service:
  path: /app/db/directory.db

api:
  grpc:
    connection_timeout_seconds: 2
    listen_address: "0.0.0.0:8282"
    certs:
      tls_key_path: "/certs/grpc.key"
      tls_cert_path: "/certs/grpc.crt"
      tls_ca_cert_path: "/certs/grpc-ca.crt"
  gateway:
    listen_address: "0.0.0.0:8383"
    allowed_origins:
    - https://*.aserto.com
    - https://*aserto-console.netlify.app
    certs:
      tls_key_path: "/certs/gateway.key"
      tls_cert_path: "/certs/gateway.crt"
      tls_ca_cert_path: "/certs/gateway-ca.crt"
  health:
    listen_address: "0.0.0.0:8484"

opa:
  instance_id: 69b537c3-8db5-11ec-8417-00c5cc9cb8c0
  graceful_shutdown_period_seconds: 2
  local_bundles:
    paths: []
    skip_verification: true
  config:
    services:
      aserto-tenant:
        url: https://discovery.prod.aserto.com/api/v1/discovery/policies
        credentials:
          bearer:
            token: "<ASERTO DISCOVERY API KEY>"
            scheme: "basic"
        headers:
          Aserto-Tenant-Id: <ASERTO TENANT ID>
    discovery:
      name: "opa/discovery"
      prefix: "3c915a8f-03cc-11ed-8afa-01c5cc9cb8c0"

controller: 

  enabled: true
  server:
    address: relay.prod.aserto.com:8443
    client_cert_path: /app/cfg/client.crt
    client_key_path: /app/cfg/client.key
  tenant_id: <ASERTO TENANT ID>
  policy_id: <ASERTO POLICY ID>


decision_logger:
  type: self
  config:
    store_directory: /app/decision_logs
    scribe:
      address: ems.prod.aserto.com:8443
      client_cert_path: /app/cfg/client.crt
      client_key_path: /app/cfg/client.key
      ack_wait_seconds: 30
      headers:
        Aserto-Tenant-Id: <ASERTO TENANT ID>
    shipper:
      publish_timeout_seconds: 2

Tell us what you think!

We hope you find these latest updates helpful, and as always we would love to hear from you - join our Slack channel today and share your thoughts.