Hybrid Disconnected Pattern¶

Introduction¶

The hybrid disconnected pattern represents the most constrained deployment model on the Azure Hybrid Continuum — environments with no connectivity to Azure, either by regulatory mandate (air-gapped security requirements) or operational necessity (remote locations, military operations, maritime deployments, classified networks). This pattern demands complete operational autonomy, requiring local alternatives for every cloud service, local identity infrastructure, and self-contained monitoring and management.

Organizations operating in defense, intelligence, critical infrastructure, and highly regulated industries often face requirements that prohibit any external network connectivity. The disconnected pattern enables these organizations to adopt modern cloud-native application architectures while meeting zero-trust and air-gap requirements.

Pattern Definition¶

Hybrid disconnected architecture eliminates all dependencies on Azure or external services:

• No network connectivity: Zero packets leave the environment (air-gapped by network design or policy)
• Local management: All operations, monitoring, and updates performed locally
• Self-hosted services: Every Azure PaaS service replaced with self-hosted alternatives
• Local identity: Active Directory Domain Services (AD DS) without cloud synchronization
• Offline updates: Software updates and patches delivered via physical media or secure one-way transfers

This pattern sacrifices the convenience of cloud management for absolute control and data sovereignty. Every capability present in cloud-native or hybrid connected patterns must be replicated locally using open-source or commercial software.

When to Use Hybrid Disconnected¶

The hybrid disconnected pattern is mandatory when:

✅ Air-gapped security required: Classified networks (Top Secret, Secret), weapons systems, nuclear facilities
✅ Regulatory prohibition: Laws explicitly prohibit cloud connectivity (some national security contexts)
✅ Zero-trust environments: Threat model assumes adversarial cloud providers
✅ Remote operations: Ships, submarines, aircraft, Antarctic research stations, offshore oil platforms
✅ Critical infrastructure: Power grids, water treatment, emergency services where internet outages cannot be tolerated

Hybrid disconnected is not suitable when:

❌ Cloud-based management is desired (use hybrid connected instead)
❌ Global distribution or multi-region deployment is required
❌ Operational teams lack expertise to manage full infrastructure stack
❌ Budget constraints prevent investment in on-premises hardware and redundancy

Reference Architecture¶

graph TB
    subgraph AirGap["Air-Gapped / Disconnected Environment"]
        subgraph Users["User Access"]
            AdminUsers[Admin Workstations]
            AppUsers[Application Users]
        end

        subgraph Identity["Identity & Access Management"]
            ADDS[Active Directory DS<br/>Domain Controllers]
            ADFS[AD FS<br/>Federation Services]
            FreeIPA[FreeIPA<br/>Linux Identity]
            Keycloak[Keycloak<br/>OAuth2/OIDC]
        end

        subgraph Compute["Compute Platform"]
            K3s[K3s / RKE2<br/>Kubernetes Cluster]

            subgraph Apps["Application Services"]
                AuthSvc[Auth Service]
                APIGw[API Gateway]
                AppSvc1[Business App 1]
                AppSvc2[Business App 2]
            end
        end

        subgraph Data["Data Services"]
            Postgres[(PostgreSQL<br/>Primary DB)]
            PostgresReplica[(PostgreSQL<br/>Replica)]
            Redis[(Redis<br/>Cache)]
            MinIO[MinIO<br/>S3-Compatible Storage]
        end

        subgraph Messaging["Messaging & Events"]
            RabbitMQ[RabbitMQ<br/>Message Broker]
            Kafka[Apache Kafka<br/>Event Streaming]
        end

        subgraph Security["Security Services"]
            Vault[HashiCorp Vault<br/>Secrets Management]
            PKI[Local PKI/CA<br/>Certificate Authority]
            SIEM[Local SIEM<br/>Security Monitoring]
        end

        subgraph Monitoring["Observability Stack"]
            Prometheus[Prometheus<br/>Metrics]
            Grafana[Grafana<br/>Dashboards]
            Loki[Loki<br/>Log Aggregation]
            Jaeger[Jaeger<br/>Distributed Tracing]
        end

        subgraph Network["Network Infrastructure"]
            FW[Firewall<br/>Segmentation]
            LB[Load Balancer<br/>HAProxy/NGINX]
            DNS[Local DNS<br/>BIND/CoreDNS]
        end

        subgraph Backup["Backup & DR"]
            LocalBackup[Veeam/Velero<br/>Local Backup]
            OffSite[Tape/Disk Rotation<br/>Off-Site Storage]
        end

        subgraph Registry["Container & Artifacts"]
            Harbor[Harbor Registry<br/>Container Images]
            Nexus[Nexus Repository<br/>Artifacts/Packages]
        end
    end

    subgraph External["Isolated Transfer Zone"]
        SecureMedia[Secure Media Transfer<br/>Air-Gap Data Diode]
        Updates[Updates & Patches<br/>Manual Transfer]
    end

    %% User Access
    AdminUsers --> ADDS
    AppUsers --> LB
    LB --> APIGw

    %% Kubernetes Apps
    K3s --> Apps
    APIGw --> AppSvc1 & AppSvc2
    AuthSvc --> Keycloak
    Apps --> Harbor

    %% Identity Flow
    ADDS --> Keycloak
    FreeIPA --> K3s
    ADDS --> ADFS
    ADFS --> AuthSvc

    %% Data Access
    Apps --> Postgres
    Apps --> Redis
    Apps --> MinIO
    Postgres -.->|Replication| PostgresReplica

    %% Messaging
    AppSvc1 & AppSvc2 --> RabbitMQ
    AppSvc1 --> Kafka

    %% Security
    Apps --> Vault
    Vault --> PKI
    FW --> K3s
    K3s & Apps --> SIEM

    %% Monitoring
    K3s & Apps & Postgres & Redis --> Prometheus
    Prometheus --> Grafana
    Apps --> Loki
    Apps --> Jaeger

    %% Network
    DNS --> K3s & Apps
    LB --> K3s

    %% Backup
    K3s & Postgres & MinIO --> LocalBackup
    LocalBackup -.->|Physical Transfer| OffSite

    %% External Updates
    SecureMedia -.->|One-Way Transfer| Harbor & Nexus
    Updates -.->|Manual Process| Harbor & Nexus

    style AirGap fill:#505050,stroke:#ffb900,stroke-width:4px,color:#fff
    style Identity fill:#b4a0ff,stroke:#5e5e5e,stroke-width:2px
    style Compute fill:#00bcf2,stroke:#0078d4,stroke-width:2px
    style Data fill:#ffb900,stroke:#d83b01,stroke-width:2px
    style Messaging fill:#7fba00,stroke:#107c10,stroke-width:2px
    style Security fill:#e74856,stroke:#a80000,stroke-width:2px
    style Monitoring fill:#00b7c3,stroke:#005b70,stroke-width:2px
    style External fill:#d83b01,stroke:#a80000,stroke-width:3px,stroke-dasharray: 5 5

Reference Architecture Components¶

Compute Services¶

Data Services¶

Messaging and Integration¶

Identity and Security¶

Monitoring and Observability¶

Container Registry¶

Continuous Integration / Continuous Deployment¶

Mapping Azure PaaS to Self-Hosted Alternatives¶

This table provides a comprehensive mapping from Azure PaaS services to disconnected alternatives:

For detailed mapping, see Appendix: PaaS-to-Self-Hosted Service Mapping.

Operations in Disconnected Mode¶

Patch Management and Updates¶

Challenge: No internet connectivity for automatic updates.

Solution:

1. Staging environment: Maintain a connected staging environment that mirrors production
2. Download updates: Download OS patches, application updates, container images in staging
3. Transfer media: Copy updates to encrypted USB drives or other secure media
4. Import to disconnected environment: Transfer media through security screening
5. Test and deploy: Apply updates in disconnected staging, then production

1. Connected Staging: Download RHEL security patches (Thursday)
2. Burn to encrypted DVD, log checksums (Friday)
3. Physical transfer via courier with chain of custody (Monday)
4. Import to disconnected staging, verify checksums (Tuesday)
5. Test patches in disconnected staging (Wednesday-Thursday)
6. Apply to disconnected production during maintenance window (Friday night)

Container Image Distribution¶

For Kubernetes workloads, container images must be pre-loaded into a local registry:

1. Build images in connected environment
2. Export images using docker save or skopeo copy
3. Transfer via secure media (encrypted USB, DVD, secure file transfer)
4. Import to Harbor registry in disconnected environment
5. Deploy to Kubernetes using local registry URL

Tool: Use skopeo for efficient image transfer:

# In connected environment
skopeo copy docker://nginx:1.25 oci-archive:nginx-1.25.tar

# Transfer nginx-1.25.tar to disconnected environment

# In disconnected environment
skopeo copy oci-archive:nginx-1.25.tar docker://harbor.local/library/nginx:1.25

Certificate Management¶

Without cloud-based certificate authorities, disconnected environments require local PKI:

• Microsoft Certificate Services: For Windows-based environments
• OpenSSL + custom CA: For Linux-based environments
• HashiCorp Vault PKI: For automated certificate issuance and rotation
• CFSSL: CloudFlare's PKI toolkit for certificate management

Best Practice: Establish a two-tier CA hierarchy:

• Root CA: Offline, air-gapped, used only to sign intermediate CAs
• Issuing CA: Online within the environment, issues certificates to services

Monitoring and Alerting¶

Deploy a full local monitoring stack:

Metrics: Prometheus scrapes metrics from all services and infrastructure, stores locally with retention policy (90 days typical). Grafana provides dashboards and alerting.

Logs: Loki or ELK stack aggregates logs from all nodes. Use Fluentd or Filebeat as log shippers.

Traces: Jaeger collects distributed traces from microservices, provides root cause analysis.

Alerting: Prometheus Alertmanager or Grafana sends alerts via local email server or SMS gateway.

Backup and Disaster Recovery¶

Without Azure Backup or Azure Site Recovery:

• VM Backup: Use Veeam, Rubrik, or native hypervisor snapshots
• Kubernetes Backup: Use Velero to backup Kubernetes resources and persistent volumes
• Database Backup: Scheduled dumps to local storage, replicated to secondary site
• Off-site backup: Physical tape or disk rotation to geographically separate location

Best Practice: Follow 3-2-1 rule: 3 copies, 2 different media types, 1 off-site.

Security Operations¶

Without cloud-based threat intelligence:

• SIEM: Deploy local SIEM (Splunk, ELK with Sigma rules) for security log analysis
• Endpoint protection: Use locally managed antivirus (Microsoft Defender ATP on-premises mode, CrowdStrike)
• Intrusion detection: Deploy Snort, Suricata, or Zeek for network traffic analysis
• Threat intelligence: Manually import threat feeds via secure media transfer

Kubernetes in Air-Gapped Environments¶

Choosing a Distribution¶

Air-Gap Installation Process¶

K3s Air-Gapped Installation:

1. Download K3s binary and air-gap images tarball in connected environment
2. Transfer to disconnected environment via secure media
3. Install K3s with --airgap-install flag, pointing to local image archive
4. K3s runs entirely from local images, no internet access required

# In connected environment
curl -sfL https://get.k3s.io | INSTALL_K3S_SKIP_START=true sh -
k3s-airgap-images-amd64.tar.gz  # Download from GitHub releases

# Transfer files to disconnected environment

# In disconnected environment
sudo mkdir -p /var/lib/rancher/k3s/agent/images/
sudo cp k3s-airgap-images-amd64.tar.gz /var/lib/rancher/k3s/agent/images/
sudo ./install-k3s.sh

OpenShift Disconnected Installation:

OpenShift supports disconnected installation via a local mirror registry. The process involves:

1. Create a local container registry (Harbor or OpenShift Registry)
2. Use oc-mirror tool to sync OpenShift release images to local registry
3. Install OpenShift pointing to the local mirror

Deploying Applications to Air-Gapped Kubernetes¶

Helm Charts:

1. Download Helm chart in connected environment: helm pull <chart>
2. Transfer chart .tgz file to disconnected environment
3. Update values.yaml to reference local container registry
4. Install: helm install -f values.yaml <chart>.tgz

GitOps (Argo CD / Flux):

1. Host Git repository locally (Gitea or GitLab CE)
2. Configure Argo CD or Flux to watch local Git repository
3. Push manifests to local Git, Argo CD/Flux deploys automatically

Identity Management in Disconnected Environments¶

Active Directory Domain Services (AD DS)¶

AD DS remains the identity backbone for disconnected Windows environments:

• Domain controllers: Deploy at least 2 DCs for redundancy
• Sites and Services: Configure AD sites to optimize replication
• Group Policy: Centralized configuration management for Windows clients and servers
• DNS integration: AD DNS for service discovery

Linux Identity: FreeIPA¶

FreeIPA provides integrated identity and authentication for Linux:

• Kerberos: Single sign-on for Linux services
• LDAP: Centralized user and group directory
• DNS: Integrated DNS for service discovery
• Certificate Authority: Built-in CA for issuing certificates

Modern Authentication: Keycloak¶

For cloud-native applications requiring OAuth2 / OIDC:

• Deploy Keycloak in HA mode (clustered, backed by PostgreSQL)
• Integrate with AD DS via LDAP user federation
• Configure realms and clients for each application
• OIDC / SAML support for modern and legacy applications

Network Architecture for Disconnected Environments¶

Segmentation¶

Apply defense-in-depth with network segmentation:

• DMZ: External-facing services (if any external access allowed)
• Application tier: Web servers, application servers
• Database tier: Databases, message brokers
• Management network: Jump boxes, monitoring, logging

Internal DNS¶

Deploy authoritative DNS servers for internal name resolution:

• AD DNS for Windows-centric environments
• FreeIPA DNS for Linux-centric environments
• CoreDNS for Kubernetes cluster DNS

Time Synchronization¶

Without internet NTP servers, deploy local NTP infrastructure:

• Stratum 1 server: GPS-based time source (hardware GPS receiver)
• Stratum 2 servers: Sync from Stratum 1, serve clients

Accurate time synchronization is critical for:

• Kerberos authentication (clock skew tolerance: 5 minutes)
• Log correlation across services
• Certificate validity checks

Preparing for Reconnection (Intermittent Connectivity)¶

Some environments operate in intermittent disconnected mode — normally air-gapped, but occasionally connected for data synchronization or updates:

Sync Patterns¶

One-Way Sync (Inbound): - Download updates, patches, container images from cloud during connection window - Import to local environment when disconnected

One-Way Sync (Outbound): - Collect logs, metrics, backup data while disconnected - Upload to cloud during connection window for analysis

Bidirectional Sync: - Git repository synchronization (pull changes, push commits) - Database replication (careful conflict resolution required)

Tools: - Rsync for file synchronization - Git for source code synchronization - Database replication (PostgreSQL logical replication, SQL Server Always On)

Automated Reconnection Procedures¶

When connectivity is restored:

1. Verify connection: Check certificate validity, test Azure endpoints
2. Sync time: Ensure NTP synchronization
3. Pull updates: Download OS patches, container images, threat intelligence
4. Push telemetry: Upload aggregated logs and metrics for analysis
5. Backup to cloud: Replicate critical data to Azure for disaster recovery
6. Disconnect: Return to air-gapped state

Security Considerations¶

Threat Model Differences¶

Disconnected environments face different threats than cloud-connected:

• Insider threats: Without cloud monitoring, detection relies on local SIEM
• Physical security: Physical access to servers becomes critical attack vector
• Supply chain: All hardware, software, and media must be verified for tampering
• Stale patches: Slower update cadence increases vulnerability window

Compensating Controls¶

Without cloud-based threat intelligence and automated response:

• Enhanced logging: Comprehensive logs of all authentication and authorization events
• File integrity monitoring: Detect unauthorized changes to system files
• Network segmentation: Limit blast radius of compromised systems
• Least privilege: Strictly enforce principle of least privilege for all accounts
• Security awareness: Train personnel on insider threat indicators

Incident Response¶

Disconnected incident response requires:

• Local forensics capability: Tools and trained personnel on-site
• Incident playbooks: Pre-defined procedures for common scenarios
• Evidence preservation: Chain of custody procedures for forensic data
• Communication plans: Out-of-band communication (phone, in-person) during incidents

Challenges and Trade-Offs¶

Operational Complexity¶

Self-managing the entire infrastructure stack requires:

• Deep expertise: Database administration, Kubernetes operations, networking, security
• Large operations team: 24/7 coverage for critical systems
• Slower innovation: Vetting and importing new technologies is time-consuming

Cost Structure¶

• High CapEx: Significant upfront investment in hardware, software licenses
• Redundancy requirements: Must provision for peak capacity (no elastic scaling)
• Slow depreciation: Hardware lifecycle is 3-5 years, cannot scale down during low usage

Disaster Recovery¶

• Geographic distribution: Requires physically separate datacenters
• Data replication: Must build custom replication solutions
• Recovery time: Longer RTO/RPO than cloud-based solutions

References¶

• Azure Stack Hub Disconnected Deployment
• K3s — Lightweight Kubernetes
• RKE2 Documentation
• Harbor Container Registry
• Prometheus Monitoring
• HashiCorp Vault
• OpenShift Disconnected Installation
• FreeIPA Identity Management

Next: Cloud Exit Pattern →

Next: Cloud Exit Pattern →