RDP
Setting the Service mode to RDP_WEB enables it to operate in browser-based Remote Desktop Protocol (RDP) mode. This mode enables your HUMAN Users to access a protected upstream RDP server (e.g. a Windows host) directly from their browsers, without installing a native RDP client and without having to share the upstream's credentials. The Service injects the credentials on-the-fly and authenticates to the upstream over Network Level Authentication (NLA), so the User reaches the desktop without ever seeing a username or password.
The RDP_WEB mode is served as a managed Service that renders the remote
desktop inside the browser. It is intended for clientless HUMAN access and
is therefore typically combined with the public "BeyondCorp" mode via the
isPublic field (read more here).
RDP_WEB mode was added in version v0.37.0. It is still experimental and might contain bugs. Please report any issues at the GitHub repository.
Secretless Access
Secretless access enables you to provide secretless access for authorized Users to an RDP_WEB-based Service by automatically injecting the username, domain and password to authenticate to the upstream RDP server. The User connects through the browser and is logged into the upstream as the user set in the Service configuration regardless of any information supplied by the downstream.
First, you need to create a Secret to store the password of the upstream RDP user (read more here) as follows:
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-passwordNow, you define your Service as follows:
kind: Service
metadata:
name: rdp1
spec:
mode: RDP_WEB
isPublic: true
config:
upstream:
url: rdp://address-to-host
rdp:
auth:
user: Administrator
domain: WORKGROUP
password:
fromSecret: rdp-passwordThe above configuration forces the User to authenticate to the upstream as Administrator in the WORKGROUP domain with the password value set in the Secret rdp-password.
The domain field is optional. If your upstream uses local accounts rather
than a domain, you can omit it.
For internal/private RDP upstreams behind NAT, you need to remotely serve them
via a connected octelium client or container as discussed
here.
Upstream TLS
The RDP_WEB mode authenticates to the upstream over an enhanced RDP security channel protected by TLS. Windows RDP servers typically present a self-signed certificate, so you need to tell the Service how to trust the upstream's certificate.
You can pin the upstream's certificate by its SHA-256 fingerprint via the pinnedCertSHA256 field as follows:
kind: Service
metadata:
name: rdp1
spec:
mode: RDP_WEB
isPublic: true
config:
upstream:
url: rdp://address-to-host
rdp:
auth:
user: Administrator
password:
fromSecret: rdp-password
upstreamTLS:
pinnedCertSHA256:
- "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08"You can provide more than one fingerprint in the pinnedCertSHA256 list, which is useful while rotating the upstream's certificate. If the upstream presents a certificate whose fingerprint does not match any of the pinned values, the connection is rejected.
Alternatively, you can disable upstream certificate verification altogether via the allowAnyCert field, which is typically recommended only for troubleshooting/testing use cases:
kind: Service
metadata:
name: rdp1
spec:
mode: RDP_WEB
isPublic: true
config:
upstream:
url: rdp://address-to-host
rdp:
auth:
user: Administrator
password:
fromSecret: rdp-password
upstreamTLS:
allowAnyCert: trueAccess Control
As with any other Service, you can control access to the RDP_WEB Service based on the identity and context of the request. Here is an example that only allows Users belonging to the ops Group:
kind: Service
metadata:
name: rdp1
spec:
mode: RDP_WEB
isPublic: true
config:
upstream:
url: rdp://address-to-host
# rest of the config
authorization:
inlinePolicies:
- spec:
rules:
- effect: ALLOW
condition:
match: '"ops" in ctx.user.spec.groups'