DataOps Agent Configuration

Configure ODM And Its Services

To access the DataOps platform functionalities directly from the Blindata UI, you must first configure the Blindata Agent to function as a reverse proxy. To do so, follow the tutorial below.

Access the Agent detail page and go to schedule.

Agent Configuration 1

Click on the FAB button, select ODM_PROXY as the Job Type and then follow the steps to create the new Job.

Agent Configuration 2

Agent Configuration 3

Each service in the job configuration should define the endpoint at which it can be accessed. Additionally, you can use servicesConfigurations to configure the following:

  • Stage Filtering: A regex pattern can be configured to match specific DataOps stages, ensuring that DevOps actions are permitted only for stages that satisfy the regex pattern
  • Authentication: When executors require authentication or authorization to process tasks effectively, they can be specified along with the necessary secrets that must be provided
{
  "servicesURLs": {
    "blueprint": "<>",
    "devops": "<>",
    "registry": "<>",
    "policy": "<>",
    "notification": "<>"
  },
  "servicesConfigurations": {
    "devops": {
      "canDeployOnlyStage": "<>",
      "executors": {
        "gitlab": {
          "secrets": [
            { "secretType": "gitlab-token" }
          ]
        }
      }
    }
  }
}

Info

Case Sensitivity: Executor names and secret types are case insensitive. Avoid using multiple executor names or secret types that differ only by case, as the system will use only a single value with all lowercase letters, which may lead to unexpected behavior.

While navigating the DataOps platform sections in the Blindata UI, you can view the current configuration in use and, if multiple configurations are available, switch to your desired one.

Agent Configuration 4

Accessing ODM Services Programmatically via API

You can access ODM services via API by targeting the agent endpoint with the configured context path. The authentication methods are the same of Blindata API.

API Endpoint Template

Use the following template to construct your API requests:

{agent-url}/agent-api/v1/odm/proxy/{odm-config-uuid}/{service-name}/{odm-service-path}

Replace the placeholders with the appropriate values:

  • {agent-url}: Base URL of the agent
  • {odm-config-uuid}: Unique identifier of the job that configures the Blindata Agent as a reverse proxy for ODM
  • {service-name}: Name of the ODM service
  • {odm-service-path}: Specific API path of the ODM service

Example

For instance, an API request may look like this:

https://demo.blindata.io/agent-api/v1/odm/proxy/563b0cc8-345e-4594-bb72-e0b2f2f343c6/policy/api/v1/pp/policy/policy-engines

Personal Secrets Integration

When making API requests through the agent proxy, you can leverage personal secrets for secure authentication. If you have previously saved personal secrets using the /agent-api/v1/config/personal-secrets endpoint, you can include them in your request headers using the following pattern:

x-odm-ag-<ExecutorName>-executor-secret-<SecretType>: <SecretName>

where:

  • <ExecutorName> is the name of the executor, as specified in the configuration
  • <SecretType> is one of the types of secrets that the executor can handle, as specified in the configuration
  • <SecretName> is the name you assigned to the secret when it was stored using the /agent-api/v1/config/personal-secrets endpoint.

The agent will automatically transform the header name to follow the pattern used by the ODM DevOps service and replace the secret name with the actual secret value, so that it can be properly forwarded to the executor. This results in the following pattern (note the removal of -ag- in the header name and the replacement of <SecretName> with <SecretValue>):

x-odm-<ExecutorName>-executor-secret-<SecretType>: <SecretValue>

In cases where the secret is not saved through the agent and you have direct access to the secret value, you can send the ODM header pattern directly to the agent. The agent will forward it to the ODM DevOps service as-is, without modifying the header name or value.

Example with Personal Secret

POST /agent-api/v1/odm/proxy/{odm-config-uuid}/policy/api/v1/policies

x-odm-ag-gitlab-executor-secret-gitlab-token: my-gitlab-token-name
x-odm-azure-executor-secret-api-key: api-key-value
Content-Type: application/json

{"policy": "data"}

This request will be forwarded as:

x-odm-gitlab-executor-secret-gitlab-token: gitlab-token-value // Transformed to ODM pattern and secret name replaced by secret value
x-odm-azure-executor-secret-api-key: api-key-value // Forwarded unchanged
Content-Type: application/json

{"policy": "data"}