Skip to content

Latest commit

 

History

History
333 lines (260 loc) · 17.1 KB

ENTERPRISE.md

File metadata and controls

333 lines (260 loc) · 17.1 KB

Enterprise Deployment & Policy Architecture


DiamTek Java Version Manager (JVM) is engineered from the ground up for high-security enterprise developer workstations, managed corporate VDI environments, and regulated automated CI/CD pipelines. Unlike legacy Unix port scripts that run with uncontrolled execution privileges and pull unverified binaries from arbitrary mirrors, DiamTek JVM provides mandatory system-wide policy enforcement, Windows Certificate Store cryptographic integration, authenticated corporate proxy support, and reproducible signed build governance.

Whether managing thousands of developer laptops through Microsoft Intune / Group Policy (GPO) or executing compliance-gated builds in air-gapped CI agents, DiamTek JVM guarantees that only authorized, verified, and audited Java runtime environments are provisioned across the enterprise.

🔍 Quick Jump


Executive Summary

DiamTek Java Version Manager bridges the gap between high developer velocity and strict enterprise governance. In regulated financial, healthcare, aerospace, and government engineering organizations, unconstrained package managers present unacceptable supply chain risks (CWE-494, CWE-295).

DiamTek JVM eliminates these risks through native Windows integration:

  • Zero-Bypass Policy Enforcement: Hardened machine configuration residing in protected %ProgramData% paths overrides all user configurations.
  • Corporate PKI Interoperability: Zero SSL interception failures (SunCertPathBuilderException) through automatic Windows Certificate Store trust inheritance.
  • Authenticated Proxy Traversal: Transparent NTLM and Kerberos domain negotiation via Windows SSPI (DefaultNetworkCredentials).
  • Reproducible Build Assurance: Cryptographic HMAC-signed toolchain lockfiles (.jvm.lock.sig) enforcing bit-for-bit build reproducibility across teams.

Machine-Wide Policy Enforcement

Policy Precedence Hierarchy

DiamTek JVM evaluates configuration and policy across three strict structural layers:

flowchart TD
    subgraph Layer1["1. Machine-Wide Administrator Policy"]
        P1["Path: %ProgramData%\\DiamTek\\JVM\\policy.toml<br>Override: $env:JVM_POLICY_FILE<br>Permissions: NT AUTHORITY\\SYSTEM + Admins (Write), Authenticated Users (Read-Only)<br>Behavior: Mandatory, Non-Bypassable"]
    end
    subgraph Layer2["2. Project-Level Declarative Lock & Configuration"]
        P2["Paths: .jvm.toml, .jvm.lock, .jvm.lock.sig<br>Behavior: Pinned to source control repository"]
    end
    subgraph Layer3["3. Developer Workstation Defaults"]
        P3["Path: %LOCALAPPDATA%\\DiamTek\\JVM\\config.json<br>Behavior: User preferences within policy boundaries"]
    end

    Layer1 -->|"Constrains & Overrides"| Layer2
    Layer2 -->|"Defaults To"| Layer3
Loading

When an enterprise policy file is present at %ProgramData%\DiamTek\JVM\policy.toml (or designated via the system-level $env:JVM_POLICY_FILE variable), DiamTek JVM runs in Governed Enterprise Mode. Any CLI flag or project configuration that conflicts with the enterprise policy is rejected with an immediate fail-closed exit code (exit 1 / Exit Code 9: Configuration Error).


Enterprise Policy Schema (policy.toml)

Below is the complete specification of the policy.toml configuration format:

# ==============================================================================
# DiamTek JVM Enterprise Policy Specification
# Path: %ProgramData%\DiamTek\JVM\policy.toml (or $env:JVM_POLICY_FILE)
# ==============================================================================

[policy]
# Prohibit bypassing SHA-256 checksum verification (--skip-checksum / --no-verify)
allow_skip_checksum = false

# Allow or restrict local user config modifications (jvm config set / reset)
allow_user_config = true

# Require a valid .jvm.lock in the project workspace
enforce_lockfile = false

# Redirect downloads to an internal corporate artifact mirror (HTTPS required)
enforced_mirror = "https://binaries.corp.internal/artifactory/jvm-cache/"

# Pin self-update and release track to certified channel ("STABLE" or "NIGHTLY")
enforced_channel = "STABLE"

[vendors]
# Only distributions from these specific vendors may be installed or activated.
# Valid options: adoptium, corretto, zulu, bellsoft, semeru, microsoft,
#                oracle, graalvm, sapmachine, mandrel, dragonwell, kona
allowed = ["adoptium", "corretto", "microsoft", "zulu"]

# Explicitly blocked vendor distributions
blocked = ["oracle"]

[versions]
# Enforce lower and upper major Java version bounds across workstations
min_java = "17"
max_java = "25"

Policy Inspection & Compliance Auditing

DiamTek JVM provides native commands for developers and automated CI systems to verify policy alignment:

1. View Active Enterprise Policy (jvm policy show)

Inspect the currently resolved machine policy, active source path, and enforced constraints:

jvm policy show

Output:

======================================================================
                  DiamTek JVM Enterprise Policy Status
======================================================================
  Policy Source        : C:\ProgramData\DiamTek\JVM\policy.toml
  Policy Enforcement   : ACTIVE (Fail-Closed)
  Allowed Vendors      : adoptium, corretto, microsoft, zulu
  Allowed Channels     : stable
  Disallow EA Builds   : YES
  Require Lockfile     : NO
  Require Signed Lock  : NO
  Internal Mirror Base : https://binaries.corp.internal/artifactory/jvm-cache/
  Corporate Proxy      : http://proxy.corp.internal:8080 (Windows Auth)
  Telemetry Disabled   : YES
======================================================================

To emit machine-readable output for compliance scanners:

jvm policy show --json

2. Audit Project Compliance (jvm policy check)

Run a pre-flight compliance check against the local workspace directory:

jvm policy check
  • Verifies that any active or configured JDK vendor is present in allowed_vendors.
  • Verifies that .jvm.lock exists if require_lockfile = true.
  • Verifies .jvm.lock.sig HMAC signature if require_signed_lockfile = true.
  • Exits with 0 on full compliance, or 1 with a detailed remediation report on failure.

Compliance Verification Workflow

flowchart TD
    Start(["jvm policy check"]) --> CheckPolicy{"policy.toml exists?"}
    CheckPolicy -- No --> AllowAll["Allow Project Config (Developer Mode)"]
    CheckPolicy -- Yes --> EnforceVendors{"Active Vendor in allowed_vendors?"}
    EnforceVendors -- No --> RejectVendor["FAIL: Vendor Blocked by Policy (Exit 9)"]
    EnforceVendors -- Yes --> CheckLockRequired{"require_lockfile = true?"}
    CheckLockRequired -- Yes --> LockExists{".jvm.lock present?"}
    LockExists -- No --> RejectLock["FAIL: Missing Required Lockfile (Exit 9)"]
    LockExists -- Yes --> CheckSigRequired{"require_signed_lockfile = true?"}
    CheckLockRequired -- No --> CheckSigRequired
    CheckSigRequired -- Yes --> SigValid{".jvm.lock.sig matches HMAC?"}
    SigValid -- No --> RejectSig["FAIL: Invalid Cryptographic Signature (Exit 9)"]
    SigValid -- Yes --> CheckEA{"disallow_ea_builds = true & EA version?"}
    CheckSigRequired -- No --> CheckEA
    CheckEA -- Yes --> RejectEA["FAIL: Early Access Builds Disallowed (Exit 9)"]
    CheckEA -- No --> Success(["PASS: Fully Compliant with Machine Policy (Exit 0)"])
Loading

Windows Certificate Store & Corporate TLS Inspection

In modern enterprise architectures, corporate firewalls and SSL/TLS proxy appliances (such as Zscaler, Palo Alto Networks, or BlueCoat) perform deep packet inspection by resigning HTTPS traffic with an internal corporate Root Certificate Authority (CA).

Legacy Tools Problem

Standard Java runtimes and open-source tools fail with PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target because they rely on an isolated, static cacerts JKS/PKCS12 file bundled inside each individual JDK installation. Developers are forced to repeatedly import enterprise certs using keytool.exe for every newly installed JDK.

DiamTek JVM Native Solution

  1. Operating System Trust Interoperability: DiamTek JVM leverages native Windows Cryptographic APIs (CryptQueryObject, CertCreateCertificateChainEngine, and CertVerifyCertificateChainPolicy) via .NET WebClient and HttpClient pipelines.
  2. Automatic Root CA Inheritance: All internal enterprise root certificates deployed by Active Directory / GPO into Cert:\LocalMachine\Root and Cert:\CurrentUser\Root are automatically recognized and trusted during download, metadata resolution, and self-update operations.
  3. Automated JDK Truststore Synchronization: When extracting a new JDK runtime, DiamTek JVM can automatically inject the Windows Trusted Root CAs into the new JDK's $JAVA_HOME\lib\security\cacerts file, ensuring developer tools (mvn, gradle, sbt, Java applications) immediately trust corporate internal endpoints without manual intervention.

Corporate PKI Trust Synchronization Flow

sequenceDiagram
    autonumber
    participant AD as Active Directory / Intune
    participant WinStore as Windows Certificate Store (LocalMachine\Root)
    participant JVM as DiamTek JVM Downloader
    participant Proxy as Corporate SSL Inspection Proxy (e.g. Zscaler)
    participant JDK as Installed JDK (lib\security\cacerts)

    AD->>WinStore: Distribute Corporate Root CA
    JVM->>WinStore: Query Trusted Root CAs (Win32 CryptAPI)
    JVM->>Proxy: Outbound HTTPS Handshake (TLS 1.2/1.3)
    Proxy-->>JVM: Re-signed Corporate TLS Certificate
    Note over JVM,Proxy: Validated against Windows Root CA Store!
    JVM->>JDK: Inject Corporate CA into cacerts (Auto-Sync)
    Note over JDK: Developer tools (Maven, Gradle) trust corporate network
Loading

Air-Gapped & Offline Environments

DiamTek JVM provides complete operational independence for disconnected environments (classified defense networks, secure banking enclaves, offline testing facilities):

1. Internal Mirror Routing

Configure restricted_mirror_base in %ProgramData%\DiamTek\JVM\policy.toml. All download requests translate vendor URLs into corporate intranet paths:

flowchart LR
    Request["Upstream Vendor Request<br>github.com/adoptium/..."] --> Engine["DiamTek JVM<br>Mirror Translator"]
    Policy["policy.toml<br>restricted_mirror_base"] --> Engine
    Engine --> Internal["Internal Enterprise Mirror<br>binaries.corp.internal/artifactory/..."]
Loading

2. Strict Offline Flag (--offline)

Developers or CI jobs can execute jvm --offline use 21 or jvm --offline list. The tool bypasses all external network resolution and operates exclusively against local Content-Addressable Storage (CAS) caches.

3. Pre-Seeded Distributions

System administrators can distribute the pre-populated %LOCALAPPDATA%\DiamTek\JVM\cache or %ProgramData%\DiamTek\JVM\cache directory as part of standard corporate OS gold images (VDI / Windows Sandbox / AMI).

4. Self-Contained Offline Distro Creation (jvm distro create)

System administrators and build engineers can generate a self-contained manager offline distribution kit (kit_type: "manager-offline-kit") on an internet-connected staging host:

jvm distro create --out C:\Distros\jvm-offline
# Or include pre-packaged active JDK and ecosystem tool payloads:
jvm distro create --out C:\Distros\jvm-offline --include-payloads

This builds an air-gapped distribution package bundling jvm.bat, auxiliary tools (tools/), install.ps1, uninstall.ps1, SHA-256 integrity digests (SHA256SUMS.txt), distro-manifest.json, and optional embedded runtime payloads (payloads/).

On the isolated or classified host, provision the workstation with zero outbound network calls:

powershell -ExecutionPolicy Bypass -File .\install.ps1 -Offline -DistroDir C:\Distros\jvm-offline

Active Directory & Microsoft Intune Deployment

GPO / Intune Deployment Recipe

To deploy DiamTek JVM across all enterprise workstations:

  1. Distribute Machine Policy: Deploy %ProgramData%\DiamTek\JVM\policy.toml via Group Policy Preferences or Intune Configuration Profiles.
  2. Set Restrictive Access Control (ACL):
    $PolicyDir = "C:\ProgramData\DiamTek\JVM"
    New-Item -ItemType Directory -Path $PolicyDir -Force | Out-Null
    
    $Acl = Get-Acl $PolicyDir
    $Acl.SetAccessRuleProtection($true, $false) # Disable inheritance, remove existing rules
    
    $AdminRule = New-Object System.Security.AccessControl.FileSystemAccessRule(
        "BUILTIN\Administrators", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow"
    )
    $SystemRule = New-Object System.Security.AccessControl.FileSystemAccessRule(
        "NT AUTHORITY\SYSTEM", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow"
    )
    $UsersRule = New-Object System.Security.AccessControl.FileSystemAccessRule(
        "BUILTIN\Users", "ReadAndExecute", "ContainerInherit,ObjectInherit", "None", "Allow"
    )
    
    $Acl.AddAccessRule($AdminRule)
    $Acl.AddAccessRule($SystemRule)
    $Acl.AddAccessRule($UsersRule)
    Set-Acl -Path $PolicyDir -AclObject $Acl
  3. Install DiamTek JVM Machine-Wide: Execute MSI silent install:
    msiexec /i jvm-windows-x64.msi /qn /norestart ALLUSERS=1

Enterprise Workstation Rollout Topology

flowchart TD
    Admin["Enterprise IT / SecOps"] --> Intune["Microsoft Intune / Active Directory GPO"]
    Intune --> Step1["1. Push policy.toml to %ProgramData%\\DiamTek\\JVM\\"]
    Intune --> Step2["2. Apply Restrictive ACLs (System/Admin Full, Users Read-Only)"]
    Intune --> Step3["3. Deploy MSI Silent Package (ALLUSERS=1)"]
    Step1 --> Workstations["Enterprise Developer Workstations"]
    Step2 --> Workstations
    Step3 --> Workstations
Loading

← Back to Documentation Overview