Redfish Proxy Configuration#

Overview#

Use this guide when DPS sends BMC Redfish requests through a Redfish proxy instead of connecting directly to each BMC. The proxy receives DPS Redfish requests and routes each request to the correct backend BMC.

This page describes the DPS-side configuration for proxy endpoint selection, routing headers, proxy authentication, TLS, topology routing data, and verification.

Prerequisites#

Before configuring DPS, make sure you have:

  • A Redfish proxy endpoint that the DPS agent pods can reach.

  • The authentication and TLS material required by the proxy.

  • Topology entities that include the field used by the routing header mapping, such as Redfish.TargetIP, Redfish.URL, Properties.MacAddress, or Properties.SerialNumber.

Configure the Proxy Endpoint#

Set dps.redfish.proxy.url to the proxy endpoint for your deployment:

dps:
  redfish:
    proxy:
      # Replace with the Redfish proxy URL for your deployment.
      url: "https://redfish-proxy.example.svc.cluster.local:1079"

When dps.redfish.proxy.url is set, DPS sends Redfish traffic through that proxy endpoint.

Configure Proxy Transport#

DPS supports proxy-specific transport settings under dps.redfish.proxy.transport. Use protocol: auto for TLS-enabled proxy services so DPS can use HTTP/2 when the proxy supports it and fall back to HTTP/1.1 when it does not. Use protocol: http1 only when the proxy requires HTTP/1.1 or has protocol negotiation issues.

The proxy transport also supports connection limits for the DPS-to-proxy connection path. These settings apply only when dps.redfish.proxy.url is set:

dps:
  redfish:
    proxy:
      # Replace with the Redfish proxy URL for your deployment.
      url: "https://redfish-proxy.example.svc.cluster.local:1079"
      transport:
        protocol: auto
        # Tune these values for the proxy capacity and expected DPS concurrency.
        maxConnsPerHost: 64
        maxIdleConns: 128
        maxIdleConnsPerHost: 64

Omit connection limit fields that you do not want to set explicitly to keep DPS defaults. When proxy mode is enabled, DPS uses one shared DPS-to-proxy connection path for read and write traffic.

Configure Routing Headers#

DPS can add Redfish request headers that carry routing metadata for a proxy. A proxy can use those header values to route each request to the correct backend BMC.

In each header entry, entityFieldValue tells DPS how to derive the header value from the target topology entity. It can be a direct dotted path such as Properties.SerialNumber, or a constrained template such as host={{ .Redfish.TargetIP }}.

Topology entities can include Redfish.URL even when dps.redfish.proxy.url is configured. In that mode, DPS uses Redfish.URL as the original Redfish target and sends the outbound request through the proxy. Header mappings can derive routing metadata from Redfish.URL:

dps:
  redfish:
    headers:
      additionalHeaders:
        - name: Forwarded
          entityFieldValue: "host={{ (url .Redfish.URL).Hostname }}"

Default Headers#

Use dps.redfish.headers.additionalHeaders to define headers that apply when the topology entity does not define the same header.

dps:
  redfish:
    headers:
      additionalHeaders:
        - name: Forwarded
          entityFieldValue: "host={{ .Redfish.TargetIP }}"

Per-Entity Topology Headers#

Use Redfish.AdditionalHeaders in the topology file when a specific entity needs its own header mapping:

Header mappings resolve values against the target topology entity. The topology configuration must include the routing field referenced by the header mapping. Common routing fields include:

  • Redfish.TargetIP

  • Properties.MacAddress

  • Properties.SerialNumber

{
  "Type": "ComputerSystem",
  "Model": "DGX_GB300",
  "Name": "node001",
  "Properties": {
    "SerialNumber": "SN-GB300-01",
    "MacAddress": "00:11:22:33:44:55"
  },
  "Redfish": {
    "TargetIP": "10.10.20.9",
    "AdditionalHeaders": [
      {
        "Name": "Forwarded",
        "EntityFieldValue": "host={{ .Redfish.TargetIP }}"
      }
    ]
  }
}

Override Headers#

Use additionalHeadersOverride when Helm values must take precedence over per-entity Redfish.AdditionalHeaders entries with the same header name. Override headers use the same entityFieldValue format as default headers; DPS still resolves the value from each target topology entity:

dps:
  redfish:
    headers:
      additionalHeadersOverride:
        - name: Forwarded
          entityFieldValue: "host={{ .Redfish.TargetIP }}"

Header precedence is, from highest to lowest:

  1. additionalHeadersOverride from DPS Helm values, for deployment-level forced header mappings.

  2. Redfish.AdditionalHeaders from each topology entity, for per-entity headers in the topology file.

  3. additionalHeaders from DPS Helm values, for deployment-level default headers.

Note: If a referenced entity field is missing, DPS skips that header entry for that entity. Authorization and X-Auth-Token are reserved and cannot be configured as additional headers.

Configure Authentication#

For proxy deployments, the most common Redfish auth methods are none and bearerToken.

Use none when DPS should not send a Redfish authentication header:

dps:
  redfish:
    auth:
      method: none

Use bearerToken when DPS should send Authorization: Bearer ... to the proxy. For a shared proxy token, set defaultSecretName to the mounted Secret name so DPS can resolve the token when the topology entity does not define Redfish.SecretName:

dps:
  redfish:
    auth:
      method: bearerToken
      defaultSecretName: redfish-proxy-bearer-token
      bearerToken:
        existingSecret: redfish-proxy-bearer-token
        existingSecretKey: token

Use session for direct BMC connections or for a proxy path that uses DPS-managed Redfish session authentication.

Configure TLS#

DPS supports insecure, tls, and mtls Redfish transport settings. For production proxy deployments, use tls or mtls with certificate verification enabled. The following example configures mTLS for a proxy that requires DPS to present a client certificate:

dps:
  redfish:
    tls:
      transportSecurity: mtls
      insecureSkipVerify: false
      certs:
        certFile: /secrets/redfish-proxy/tls.crt
        certKeyFile: /secrets/redfish-proxy/tls.key
        caFile: /secrets/redfish-proxy/ca.crt

  secrets:
    - name: dps-redfish-proxy-client
      secretKey: tls.crt
      mountPath: /secrets/redfish-proxy/tls.crt
    - name: dps-redfish-proxy-client
      secretKey: tls.key
      mountPath: /secrets/redfish-proxy/tls.key
    - name: dps-redfish-proxy-client
      secretKey: ca.crt
      mountPath: /secrets/redfish-proxy/ca.crt

Verify the Configuration#

After deployment, validate, import, and activate the topology before running Redfish reachability checks. DPS 0.9 requires an active topology for both commands. Follow Managing Topologies for activation prerequisites and effects:

dpsctl topology validate topology.json
dpsctl topology import topology.json
dpsctl topology activate --topology <topology-name>
dpsctl topology list --active
dpsctl check connection --topology <topology-name>
dpsctl verify bmc-health start --topology <topology-name> --skip-writes --wait --summary-only

Start with --skip-writes so the first health check is read-only.

Example: NVIDIA Infra Controller (NICo)#

This example shows DPS configured with NVIDIA Infra Controller (NICo) nico-bmc-proxy. DPS authenticates to the proxy with mTLS, sends routing metadata in the Forwarded header, and uses redfish.auth.method: none.

dps:
  redfish:
    proxy:
      # Replace with the NICo BMC proxy service URL for your deployment.
      url: "https://nico-bmc-proxy.nico-system.svc.cluster.local:1079"
    auth:
      method: none
    tls:
      transportSecurity: mtls
      insecureSkipVerify: false
      certs:
        certFile: /secrets/nico-bmc-proxy/tls.crt
        certKeyFile: /secrets/nico-bmc-proxy/tls.key
        caFile: /secrets/nico-bmc-proxy/ca.crt
    headers:
      additionalHeaders:
        - name: Forwarded
          entityFieldValue: "host={{ .Redfish.TargetIP }}"

  secrets:
    - name: dps-nico-bmc-proxy-client
      secretKey: tls.crt
      mountPath: /secrets/nico-bmc-proxy/tls.crt
    - name: dps-nico-bmc-proxy-client
      secretKey: tls.key
      mountPath: /secrets/nico-bmc-proxy/tls.key
    - name: dps-nico-bmc-proxy-client
      secretKey: ca.crt
      mountPath: /secrets/nico-bmc-proxy/ca.crt

For this NICo proxy path, do not create or mount DPS-owned BMC credential secrets. The topology does not need Redfish.URL or Redfish.SecretName because the proxy routes each Redfish request to the backend BMC and owns BMC credential management.