RDP

Octelium provides two Remote Desktop Protocol (RDP) modes:

RDP serves ordinary RDP clients over the client-based mode. It is not available through clientless access.
RDP_WEB renders the remote desktop in a browser for clientless HUMAN access. It does not require a native RDP client.

Both modes can authenticate to an upstream Windows host over Network Level Authentication (NLA), inject upstream credentials from a Secret, verify the upstream TLS certificate and apply identity-based access control.

Setting the Service mode to RDP enables native RDP access. The User first connects to the Cluster with the octelium client and then opens the Service private FQDN with Microsoft Remote Desktop, mstsc, FreeRDP or another RDP client.

Here is a minimal Service that passes the credentials entered in the downstream RDP client to the upstream:

kind: Service
metadata:
  name: desktop
spec:
  mode: RDP
  port: 3389
  config:
    upstream:
      url: rdp://windows.internal:3389

After connecting to the Cluster, a User authorized to access the Service can open desktop.local.example.com in their RDP client. Replace example.com with the Cluster domain. The default port for RDP is 3389, so the port field can be omitted when the default is suitable.

note

The RDP mode is available only through client-based access. Do not set isPublic: true to expose it. Use RDP_WEB when the remote desktop must be available through a browser without the octelium client.

note

For internal RDP upstreams behind NAT, remotely serve the Service through a connected octelium client or container as discussed here.

RDP Web

Setting the Service mode to RDP_WEB enables browser-based RDP. A HUMAN User opens the public Service URL and uses the remote desktop directly from the browser.

kind: Service
metadata:
  name: desktop
spec:
  mode: RDP_WEB
  isPublic: true
  config:
    upstream:
      url: rdp://windows.internal:3389

note

The RDP_WEB mode is a managed Service intended for clientless HUMAN access and is therefore typically combined with the public BeyondCorp mode through isPublic (read more here).

note

RDP_WEB was added in version v0.37.0. It is still experimental and might contain bugs. Please report issues at the GitHub repository.

Secretless Access

Both RDP and RDP_WEB support secretless upstream authentication. Octelium performs NLA authentication to the upstream using a username, optional Windows domain and password stored in a Secret. The downstream User never needs a valid upstream credential.

First, create a Secret containing the password:

octeliumctl create secret rdp-password
# OR via a --value flag
octeliumctl create secret --value <PASSWORD> rdp-password
# OR via a --file flag
octeliumctl create secret --file /PATH/TO/PASSWORD rdp-password

Add the injected credential to the Service:

kind: Service
metadata:
  name: desktop
spec:
  mode: RDP
  config:
    upstream:
      url: rdp://windows.internal:3389
    rdp:
      auth:
        user: Administrator
        domain: WORKGROUP
        password:
          fromSecret: rdp-password

The Service authenticates to the upstream as Administrator in the WORKGROUP domain. In native RDP mode, the configured credential overrides credentials supplied by the downstream RDP client. For browser access, change mode to RDP_WEB and set isPublic: true; the rdp.auth configuration remains the same.

note

The domain field is optional for local accounts. The user field is required when password.fromSecret is set.

Upstream TLS

Both RDP modes use a TLS-protected enhanced RDP security channel to the upstream. Windows RDP servers commonly present self-signed certificates. For production use, pin the accepted upstream certificate fingerprints with pinnedCertSHA256:

kind: Service
metadata:
  name: desktop
spec:
  mode: RDP
  config:
    upstream:
      url: rdp://windows.internal:3389
    rdp:
      upstreamTLS:
        pinnedCertSHA256:
          - "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08"

More than one fingerprint can be provided during certificate rotation. Colons in a fingerprint and the sha256/ prefix are accepted. The connection is rejected when the upstream certificate matches none of the configured fingerprints.

You can disable upstream certificate verification with allowAnyCert:

rdp:
  upstreamTLS:
    allowAnyCert: true

Access Control

Access to both RDP and RDP_WEB Services is authorized when the connection starts. Conditions can use the User, Groups, Session, Device and other request context. This example restricts access to members of the ops Group:

kind: Service
metadata:
  name: desktop
spec:
  mode: RDP
  config:
    upstream:
      url: rdp://windows.internal:3389
  authorization:
    inlinePolicies:
      - spec:
          rules:
            - effect: ALLOW
              condition:
                match: '"ops" in ctx.user.spec.groups'

RDP does not expose desktop activity as individual application-layer requests. Authorization therefore applies to the connection rather than to actions performed inside the remote desktop.

Dynamic Configuration

Dynamic configuration can select a different upstream or injected credential from identity and context (read more here). In this example, members of the ops Group receive the administrator credential while other authorized Users receive an unprivileged credential:

kind: Service
metadata:
  name: desktop
spec:
  mode: RDP
  dynamicConfig:
    configs:
      - name: administrator
        upstream:
          url: rdp://windows.internal:3389
        rdp:
          auth:
            user: Administrator
            password:
              fromSecret: admin-password
          upstreamTLS:
            pinnedCertSHA256:
              - "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08"
      - name: user
        upstream:
          url: rdp://windows.internal:3389
        rdp:
          auth:
            user: rdp-user
            password:
              fromSecret: user-password
          upstreamTLS:
            pinnedCertSHA256:
              - "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08"
    rules:
      - condition:
          match: '"ops" in ctx.user.spec.groups'
        configName: administrator
      - condition:
          matchAny: true
        configName: user

The same dynamic configuration structure is supported by RDP_WEB.