You can run the OutSystems Cloud Connector container in AKS as non‑root, but you need to align your securityContext with how the image is built and with the permissions of the host/network it’s running on.

From the product docs, the key points are:

• The Cloud Connector is a Linux-based client that doesn’t require root and only needs outbound internet access; it doesn’t expose inbound endpoints in your private network.Securely tunnel your way into your private network with ODC
• It’s available as a Docker image from the OutSystems registry and is meant to run as a lightweight container in environments like AWS, Azure, or on-prem.Securely tunnel your way into your private network with ODC
• Networking-wise, it only creates outbound SSH tunnels to the Private Gateway service; there’s no requirement for privileged ports or host networking.Securely tunnel your way into your private network with ODC

Because the image itself doesn’t require root, the usual non‑root Kubernetes hardening applies well:

1. runAsNonRoot and privilege escalation

These flags are safe and recommended:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false

The connector doesn’t need to start privileged processes, load kernel modules, or manipulate low‑level networking, so allowPrivilegeEscalation: false won’t block it.

2. runAsUser / runAsGroup

The exact UID/GID will depend on how OutSystems built the image, but in practice you have two options:

1. Let the image define the user
   If the connector image sets a non‑root USER in its Dockerfile, you can rely on that and simply do:

   securityContext:
     runAsNonRoot: true
     allowPrivilegeEscalation: false
   

   This is the simplest and usually works if the container logs don’t show any permission errors.

2. Force a specific non‑root UID/GID
   If your cluster has a policy that forces explicit UIDs, pick an arbitrary non‑root user that matches your compliance rules (for example 1000), and only mount volumes that are writable by that UID:

   securityContext:
     runAsNonRoot: true
     runAsUser: 1000
     runAsGroup: 1000
     allowPrivilegeEscalation: false
   

   This works as long as:

   • The image doesn’t rely on a hard‑coded UID/GID.
   • There’s no need to write to root‑owned filesystem paths in the container.
   • Mounted volumes (if any) are owned or writable by UID 1000.

If your first attempt fails with permission errors, you’ll see them in the connector logs (e.g. unable to create temp files, config files, or SSH sockets). In that case, either adjust runAsUser or fix volume ownership.

3. Other securityContext considerations

To keep it locked down but functional:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000            # or whatever is compliant in your AKS
  runAsGroup: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: false  # usually needed, the connector may write logs/temp
  capabilities:
    drop: ["ALL"]

You can try readOnlyRootFilesystem: true, but expect to potentially need writable space (/tmp or an attached volume) for logs and SSH sockets.

4. Network and firewall requirements

Running non‑root doesn’t change the core network requirements:

• The pod must be able to open outbound TCP connections to the Private Gateway address provided in the ODC portal when you activate the service.Securely tunnel your way into your private network with ODC
• No inbound ports need to be open on the container or node; the connector only establishes tunnels outwards.Securely tunnel your way into your private network with ODC

5. Practical validation steps

1. Deploy a test pod with:

   securityContext:
     runAsNonRoot: true
     runAsUser: 1000
     runAsGroup: 1000
     allowPrivilegeEscalation: false
   

2. Start the connector using the documented parameters (token, gateway URL, remote connections).Securely tunnel your way into your private network with ODC

3. Monitor:

   • Container logs for permission-related errors.
   • Connectivity (e.g. test a private DB connection using the secure-gateway hostname from ODC portal).Securely tunnel your way into your private network with ODC

If logs are clean and the ODC connection test succeeds, your chosen runAsUser/runAsGroup and non‑root setup are valid.

Since OutSystems doesn’t mandate a specific UID/GID for the Cloud Connector in the public docs, you’re free to pick any non‑root ID that fits your AKS security policies, provided volumes and filesystem permissions are aligned.