Skip to main content

Deploy OPA Tokens for Microservices

OPA talks to DAS over HTTPS: OPA sends HTTPS calls to download bundles from DAS, and HTTPS calls to upload status updates and decisions made back to DAS. The communication is both encrypted and authenticated. TLS provides the encryption of the communication channel and bearer tokens authenticate OPA to DAS.

This page describes how to manage these bearer tokens in an operational setting. For example, how to issue and rotate the tokens for improved security.

When installing a new system, DAS prepares the OPA configuration files and Kubernetes manifests to use in installing. The files are ready to use and therefore, the OPA configuration file also includes a bearer token for OPA to use in its communication with DAS. This default OPA configuration file is non ideal for token rotation. However, when it embeds the token, it is important to update the token and the configuration file. For easier token rotation, it is useful to separate the token management from the configuration management. For this purpose, DAS allows you to create a new bearer token without retrieving or updating the OPA configuration file. This can be done with the DAS GUI (manually) or with the DAS /v1/tokens API (programmatically). Similarly, OPA allows providing the token outside of the configuration file, in a file separate from the configuration.

Configure OPA to use a Token​

This section explains how to deploy the separate configuration and token files to Kubernetes, and to allow easy token rotation. Styra demonstrates the details of using Kubernetes; however, the concepts apply in other environments as well.

The default OPA installation provided by DAS saves the OPA configuration file into a Kubernetes configuration map. In addition to this, create a new Kubernetes secret to save the current, active bearer token. Again, this token can be obtained from DAS, either through GUI or API. Then, similarly to the OPA configuration file, this secret can be volume mounted to the pod, as follows.

For more information on using secret volumes, see Consuming Secret Values from Volumes page.

  • Introduce a new volume in the specification part of the Deployment resource.

    volumes:
    - name: opa-secret-vol
      secret:
        secretName: opa-token

  • Mount the new volume in the container by introducing a new volume mount to the OPA container in the Deployment resource.

    volumeMounts:
    - readOnly: true
      mountPath: /secret
      name: opa-secret-vol

Once mounted, the contents of the opa-token secret are now available for the OPA container, under /secret directory. That is, assuming the secret contains a key token, the token will be available at /secret/token for OPA. Finally, to inform OPA that the token should be loaded from that file instead of the configuration file, OPA's ConfigMap should read like this:

kind: ConfigMap
apiVersion: v1
metadata:
  name: opa-config
  namespace: opa
data:
  opa.yaml: |
    discovery:
      name: discovery
      prefix: /systems/YOUR_DAS_SYSTEM_ID
      service: styra
    labels:
      system-id: YOUR_DAS_SYSTEM_ID
      system-type: custom
    services:
    - credentials:
        bearer:
          token_path: /secrets/opa-token # <---- NOTE THIS
      name: styra
      url: https://YOUR_DAS_TENANT.svc.styra.com/v1
    - credentials:
        bearer:
          token_path: /secrets/opa-token # <---- AND THIS
      name: styra-bundles
      url: https://YOUR_DAS_TENANT.svc.styra.com/v1/bundles

At this point, OPA loads its bearer token from the Kubernetes secret as it boots and the token can be rotated by updating the secret holding the token. However, you should note that OPA does not reload the file after booting, so to activate the token change you should restart the OPA pods after updating the secret.

Automate the Token Rotation​

Automating the token creation and rotation entirely requires a software component to implement the above operations. The exact details of this software component are likely to be specific to the cluster and environment it operates within, but the component’s responsibilities is described in this section. It is the responsibility of the software responsible for deploying, updating, and deleting resources on the cluster. The software component is also called as the Cluster Manager.

The Cluster Manager is responsible for creating a DAS system for each OPA deployment on the cluster, and minting any necessary tokens for OPA. For these operations, it needs to access the DAS API and must have a bearer token to access it. This bearer token is long-lived. Depending on the operating environment and operational best practices, you can determine how it is exactly provided for the cluster manager.

Each OPA deployment corresponds to a single DAS system. To rotate the tokens for OPA, the cluster-manager will periodically generate new tokens granted access to that DAS system and then redeploy those tokens to OPA.

The initial token is part of the install instructions generated by the system, which you can retrieve through a GET on v1/systems (or the corresponding API call). Tokens in the DAS have human-readable names; the initial token is named v1/tokens/system/<id>/opa.

To generate a new token, the Cluster Manager runs v1/tokens. Ideally, you create tokens that grant only the minimal permissions necessary for OPA; specifically, access to the following URL paths:

  • /v1/systems/<system id>/discovery
  • /v1/bundles/<system id>
  • /v1/status
  • /v1/logs

The following shows a sample API call to create such a token. Notice, it requires the long-lived bearer token to communicate with the DAS and it restricts the paths permitted to those listed above and grants a TTL of 5 hours:

curl -H 'Authorization: Bearer MY_TOKEN' -H 'Content-Type: application/json' https://Tenant.styra.com/v1/tokens/systems/SYSTEM_ID/opa -X PUT -d '{"regenerate": true}'
important

You must replace Tenant, SYSTEM_ID ID, and MY_TOKEN in the API calls.

Each time the Cluster Manager runs this API call to generate a new token, it must redeploy that token to OPA. In the above example with OPA running on Kubernetes, this would entail updating the Kubernetes secret that contains the token and restarting OPA, if required.