Using the SAS Configurator for Open Source in Dark‑Site Environments

Deploying SAS Viya's open-source integrations in environments with no internet access, commonly called dark sites or air-gapped environments, presents unique operational and security considerations and specific task.

SAS Viya 2024.11 introduced important enhancements to the SAS Configurator for Open Source that make it simpler and more reliable to provision Python runtimes and packages in offline clusters.

SAS Viya 2025.08 further reduced friction by leveraging the platform truststore for jobs.

This post explains the recent Configurator enhancements and why they matter, presents a Kubernetes-native reference architecture for delivering Python runtimes and package indexes into air-gapped clusters, outlines practical steps to prepare and validate signed Python tarballs and wheelhouses, and provides a short checklist and operational tips to keep offline Python integrations secure, repeatable, and easy to maintain.

Why Offline Python Integration Matters

Modern analytics workflows depend on Python and its package ecosystem. Internet-connected environments, pip installs and runtime provisioning are routine. In dark-site deployments you must explicitly provide:

A Python runtime tarball, its detached signature, and the signer public key.
An HTTP(S) accessible package index that conforms to PEP 503 (the Simple Repository API).
A trusted CA chain so pods can validate TLS endpoints.

The SAS Configurator for Open Source now gives explicit parameters to point at these internal resources, making offline deployments repeatable, auditable, and secure.

Security can also be a concern: internal package repositories and wheelhouses are commonly scanned by vulnerability scanners (SCA tools) that check for known CVEs and insecure dependencies, so artifact provenance, signature verification and controlled updates are critical.

Key Enhancements in SAS Viya 2024.11

The SAS Configurator for Open Source adds parameters that let administrators direct pip and Python operations to internal mirrors:

pip_index_url - primary pip index used for pip installs (must be PEP 503 compliant).
pip_extra_url - optional supplemental repositories.

For air-gapped deployments, these SAS Configurator for Open Source parameters are mandatory:

python_tarball - HTTP/HTTPS URL to the Python distribution tarball.
python_signature - HTTP/HTTPS URL to the tarball's signature (.asc).
python_signer - HTTP/HTTPS URL to the signer public key (.asc).
pip_index_url - HTTP/HTTPS URL to a PEP 503-compliant index.
pip_extra_url - optional supplemental repositories.

The tarball and signature must be reachable from the cluster. The pip index must expose the standard /simple endpoint that pip uses.

Key Enhancements in SAS Viya 2025.08

The SAS Configurator for Open Source now reuses the SAS Viya platform truststore for jobs configuring Python and R. In practical terms:

Add custom CAs to the Viya platform truststore as you would for other Viya applications.
Job containers created by the SAS Configurator for Open Source will use those trust anchors, you do not need separate configurator-specific certificate steps.

This centralizes certificate management and reduces operational overhead.

Architecture options for dark-site artifact delivery

There is no one-size-fits-all architecture for delivering Python runtimes and packages into air-gapped environments. Below are common patterns you can choose from depending on your organization's constraints and existing tooling.

The core requirement across all options is that the Python tarball, signatures, and wheel files are served over HTTP(S) from a trusted, reachable endpoint and that the package index exposes a PEP 503 /simple index.

Option	Description	Pros	Cons
Enterprise artifact repository	Use Nexus, Artifactory, Harbor or equivalent. These products provide proxying, mirroring, access control and storage lifecycle features. They can host raw files (Python tarballs and signatures) and expose a PEP 503-compatible PyPI proxy or hosted repository for wheels.	Robust enterprise features; familiar to many operations teams; fine-grained access control and auditing.
Internal HTTP server + static wheelstore	Serve static tarballs and wheels from an internal HTTP server (NGINX, Apache, or an object store with an HTTP gateway). For PyPI-style indexes you can either run a lightweight index server (pypiserver, simpleindex) or generate a static /simple directory structure that pip understands.	Simple to operate; minimal components; easy to audit and version.
Combined mirror in-cluster (Kubernetes-native)	Place artifacts inside the cluster (for example an HTTP server and index running as Deployments/Services with PVCs) to simplify network policies and make endpoints reachable without external routing.	Network locality; reduced external dependencies.	Requires cluster resources and backup/restore processes for artifacts.
Hybrid model with secure transfer	Maintain canonical artifacts in a secure, internet-connected environment, then transfer them into the air-gapped environment using secure CI/CD pipelines, signed artifact bundles, or removable media. Validate signatures after transfer.	Separates internet-facing caching from the air-gapped runtime; good for high-security environments.

Prefer enterprise artifact repositories where available. If you must run lightweight services, ensure they are regularly backed up and accessible from sas-pyconfig and job pods. For the highest security posture, combine artifact signing, immutable paths and audited transfer procedures.

How to Prepare and Validate Artifacts

The following generic guidance applies across environments:

Acquire the Python distribution tarball, its detached signature and the signer public key from a trusted source. Verify the tarball locally with GPG before creating any internal copies.
Build or assemble a wheelhouse for required packages that matches the target Python ABI and platform (manylinux tags for Linux builds). Where possible, prefer prebuilt wheels compatible with your Viya environment to avoid compiling during deployment.
Pro tip: You can use a connected staging environment to build and test your Python wheelhouse, then mirror the verified artifacts into your dark site. Tools like pip download or devpi can help automate this mirroring.
Serve artifacts over HTTP(S). Ensure the package index complies with PEP 503: pip clients use the /simple endpoint to discover packages and links to wheel files.

Secure access and certificates. If using HTTPS, add any internal CAs to the Viya platform truststore (Viya 2025.08+ lets SAS Configurator for Open Source jobs reuse this truststore).

Version and immutability. Use versioned filenames or content-addressed artifact paths to make rollbacks and audits straightforward.

Validate from the platform. Before executing a large SAS Configurator for Open Source run, exec into a staging sas-pyconfig pod (or equivalent job) and verify:

the Python tarball and signature are downloadable via curl/wget,
GPG signature verification works,
pip can reach the /simple index and download a test wheel.

Automate transfers. Use CI/CD pipelines, signed bundles, or approved operator procedures to move artifacts into the air-gapped environment rather than ad-hoc manual copy operations.

This more generic approach makes the guidance applicable whether you choose Nexus, a static HTTP server, an in-cluster mirror, or a hybrid transfer model.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

Example SAS Configurator for Open Source parameter values (conceptual)

Set SAS Configurator for Open Source config keys to point to internal resources:

python_tarball = https://myownenv.sas.com/nexus/repository/raw/Python-3.11.10.tgz
python_signature = https://myownenv.sas.com/nexus/repository/raw/Python-3.11.10.tgz.asc
python_signer = https://myownenv.sas.com/nexus/repository/raw/Python-3.11.10.tgz.signer.asc
pip_index_url = https://myownenv.sas.com/nexus/repository/pypi-proxy

Always confirm each URL is reachable from the sas-pyconfig pod before running a large-scale job.

What success looks like (logs and validation)

A clean run typically shows:

The SAS Configurator for Open Source validates and uses the provided pip_index_url.
The Python tarball and signature are downloaded and GPG verification succeeds.
Required pip packages are installed from the internal index.

Look for condensed, positive log lines such as:

Using pip-index-url http://pypi…/simple for remote pip calls
Python tarball curl success
Pip package install success

If you see repeated 404/403 on /simple or TLS certificate validation errors, check index correctness, HTTP paths and certificate trust.

Conclusion

These Configurator improvements make offline Python integration feel straightforward and empowering. Signed tarballs, explicit pip index parameters, and reuse of the Viya truststore let teams deliver reliable, auditable Python runtimes into locked‑down clusters. Pick the artifact delivery pattern that fits your ops model and automate the rest. The result: faster, safer deployments and more time for analytics, not plumbing.