Overview

JCC hardened mode applies OS-level isolation to a Groundplex JCC node that runs in Docker or Kubernetes. When enabled, the jcc.sh startup script hides sensitive host configuration from the JCC process and drops the Linux capabilities and privileges the process could otherwise inherit. This limits the blast radius of a Script Snap or a third-party Snap Pack that attempts to read sensitive host files such as /etc/shadow or on-disk cloud-provider credentials. Hardened mode isolates the file system; it does not restrict network access to endpoints such as the instance metadata service (see Limitations).

Hardened mode provides two independent protections, each controlled by its own environment variable:

• Hide system files (JCC_HIDE_SYSTEM_FILES) — Replaces /etc, /var, and /root with minimal, sparse versions inside a private mount namespace, hiding host secrets from the JCC process. Requires the CAP_SYS_ADMIN Linux capability.
• Block admin rights (JCC_BLOCK_ADMIN_RIGHTS) — Starts the JCC with no ability to gain new privileges and with all inheritable capabilities cleared. Requires no special capability.

You can enable both protections at once with the umbrella variable JCC_HARDENED_MODE=true, or enable either protection individually. All three variables are disabled by default.

Prerequisites

• A containerized Groundplex node (Docker or Kubernetes) based on the SnapLogic JCC image.
• The setpriv utility must be present in the container image. The default SnapLogic JCC image (based on AlmaLinux 9) includes it.
• For JCC_HIDE_SYSTEM_FILES (and therefore for JCC_HARDENED_MODE), the container must be granted the CAP_SYS_ADMIN Linux capability, which the script uses to create a mount namespace and bind-mount the sparse directories.
• JCC_BLOCK_ADMIN_RIGHTS on its own requires no additional capability.

Enable hardened mode

1. Confirm your container image includes setpriv (the default SnapLogic JCC image does).
2. Set JCC_HARDENED_MODE=true as an environment variable on the container. To enable only one protection, set JCC_HIDE_SYSTEM_FILES=true or JCC_BLOCK_ADMIN_RIGHTS=true instead. A variable enables its protection only when set to the exact string true.
3. If you enable file-system hiding, grant the container the SYS_ADMIN capability.
4. Start the container and verify that isolation is active (see Verify that isolation is active).

docker run -itd \
  -e JCC_HARDENED_MODE=true \
  --cap-add=SYS_ADMIN \
  --name <container_name> \
  <jcc_image>:<tag>

spec:
  containers:
  - name: jcc
    image: <jcc_image>:<tag>
    securityContext:
      capabilities:
        add:
        - SYS_ADMIN
    env:
    - name: JCC_HARDENED_MODE
      value: "true"

What is isolated and what remains writable

When JCC_HIDE_SYSTEM_FILES is active, the script builds sparse copies of /etc, /var, and /root and bind-mounts them over the real directories inside a private mount namespace. The sparse /etc contains only the entries the JCC needs to run — for example, name resolution and TLS files (resolv.conf, hosts, nsswitch.conf, localtime, release files, crypto-policies, pki, ssl, and the loader cache) along with passwd and group entries filtered to the root and SnapLogic users. Host secrets outside this set, such as /etc/shadow and cloud credential files, are no longer visible to the JCC process.

The following directories remain writable by the JCC:

• /opt/snaplogic/run/
• /opt/snaplogic/data/
• /opt/snap_v4/ (the SnapLogic home directory)

Verify that isolation is active

On startup, the JCC logs its hardening actions. When file-system hiding succeeds, the log includes messages such as:

Applying JCC hardening: hide system files (sparse /etc, /var, /root)...
Sparse /etc mounted successfully
Sparse /var mounted successfully
Sparse /root mounted successfully
Filesystem isolation applied successfully

You can also run JCC diagnostic mode, which reports the requested hardening and the verified runtime status. The report shows, per protection, whether it is active — for example, the mount status for /etc, /var, and /root, whether a read of /etc/shadow is denied, and the process NoNewPrivs and inheritable-capability values.

Limitations

• Hardened mode is opt-in and disabled by default.
• JCC_HIDE_SYSTEM_FILES (and therefore JCC_HARDENED_MODE) requires the CAP_SYS_ADMIN capability. If the capability is not available, the JCC fails to start rather than starting without isolation. To run without a capability, use JCC_BLOCK_ADMIN_RIGHTS alone, which does not require CAP_SYS_ADMIN.
• Snaps, pipelines, or scripts that read or write files outside the writable directories fail when file-system hiding is enabled.
• The setpriv utility must be present in the container image.
• Network isolation (for example, restricting access to the cloud metadata endpoint) is a separate, customer-managed configuration and is not enabled by hardened mode.

Troubleshooting