Project Summary

Migrated a data governance vendor’s hybrid connectivity agent off an end-of-support Windows deployment onto Azure Kubernetes Service, deliberately choosing a managed cloud platform over the vendor’s own bare-metal recommendation. Along the way, the team isolated an undocumented ARM64 compatibility limitation in the vendor’s own product, one that hadn’t been identified during initial vendor support troubleshooting, and worked with the vendor to get it running on a supported x86-64 configuration, while independently developing product-specific Kubernetes hardening where vendor guidance was limited. The agent now connects the organization’s data governance catalog to internal databases and the data warehouse, with Databricks integration in progress.

Problem

The organization’s data governance catalog relied on a vendor-provided connectivity agent to reach data sources across the organization: internal databases, the data warehouse, and eventually the Databricks environment described elsewhere in this portfolio. The existing deployment of that agent ran on Windows, and Windows support for it was going away. Continuing to support and evolve the platform meant a real migration, not a patch.

The vendor’s own guidance pointed toward deploying the replacement on bare-metal Kubernetes. Nobody on the team had deployed Kubernetes before, so this wasn’t just a platform migration; it was learning an entirely new deployment model under a support deadline, while also deciding whether to follow the vendor’s own recommended path or build something more sustainable.

Constraints

• The prior Windows-based deployment was losing vendor support; this wasn’t optional or schedulable at leisure.
• No prior Kubernetes experience on the team; the platform had to be learned, not just operated.
• The vendor’s own recommended deployment target was bare-metal Kubernetes.
• Vendor-specific documentation for securing a Kubernetes deployment of their product was limited; general Kubernetes and AKS security guidance existed, but not for this particular workload.
• The agent needed real network connectivity to internal databases, the data warehouse, and, eventually, Databricks, not just a running cluster in isolation.
• Whatever was built had to satisfy the organization’s existing Azure Policy controls, which hadn’t been designed around this specific vendor workload.

Architecture

Choosing AKS Over the Vendor’s Bare-Metal Recommendation

Rather than stand up and operate a separate bare-metal Kubernetes platform for what was fundamentally a single vendor workload, the team deployed onto Azure Kubernetes Service instead. That decision meant taking on Azure’s own governance and policy model as part of the deployment, something bare metal wouldn’t have forced, but it traded away the ongoing burden of managing physical Kubernetes infrastructure for a managed control plane, integrated into the Azure networking, identity, and governance patterns the organization already operated everything else under.

Scoping Azure Policy Around an Unanticipated Workload

The organization’s existing Azure Policy controls enforce generic rules against pods, containers, and namespaces, things like allowed registries, required security contexts, and resource-level constraints, not a registry of which vendors are “trusted.” Those controls simply hadn’t been designed with this workload in mind, so the initial deployment ran straight into policy conflicts. Rather than disabling enforcement broadly, the team worked out specific, intentional exclusions and allowances scoped to what this workload actually needed, narrow enough that policy still does its job everywhere else, though some friction remains where the vendor’s requirements don’t cleanly line up with the organization’s standard controls.

Developing Product-Specific Kubernetes Hardening

Vendor-specific guidance for securing this particular product’s Kubernetes deployment was limited; Microsoft’s own AKS security guidance exists, but applying it correctly to this workload’s specific pod permissions, network access, and secrets handling wasn’t something the vendor had documented. Locking down the pods was worked out independently, without a vendor reference architecture to lean on.

Connecting the Catalog to Its Actual Data Sources

Beyond standing up the infrastructure, the agent itself had to be configured with the right drivers to reach the organization’s various data sources, internal databases and the data warehouse initially, with Databricks connectivity now underway. Getting that working meant troubleshooting real network paths between pods running in AKS and systems that predate this project by years, not just configuring the vendor product in the abstract. Roughly a dozen data sources are connected through the agent today, with room to grow as adoption continues.

Operating AKS as a Production Platform, Not a One-Time Migration

The cluster was built from scratch, including Azure Key Vault integration so the agent’s connection secrets, the credentials it uses to reach each connected data source, are managed outside the cluster rather than embedded in deployment configuration. Routine node maintenance runs through Azure’s own patching, but staying current goes further than that: AKS versions get promoted deliberately rather than left to drift, and core components that standard patching doesn’t reach get updated by hand. When last year’s independent security audit for the environment surfaced findings beyond what Microsoft Defender for Cloud’s own recommendations had already covered, those got remediated too; this wasn’t built once and left alone.

Engineering Challenges

An Undocumented ARM64 Compatibility Limitation

The AKS cluster itself looked healthy right up until the vendor’s actual product was deployed onto it. From there, failures that made no obvious sense started showing up, nothing that immediately pointed to infrastructure or Kubernetes itself. It took roughly a month of troubleshooting, much of it working directly with the vendor’s own support team, to isolate the actual cause: the vendor workload supported x86-64 nodes but not the ARM64-based nodes originally provisioned for the cluster. AKS itself supports ARM64 node pools without issue; this wasn’t a platform limitation, it was a workload-level compatibility requirement the vendor hadn’t documented, and one their own support team hadn’t identified going in either. Resolving it required moving past the visible symptoms, isolating the actual runtime dependency, and working jointly with the vendor to establish a supported x86-64 configuration.

Governance for a Workload Azure Policy Wasn’t Designed Around

The harder part wasn’t writing the exceptions; it was deciding which policy failures represented a genuine security gap and which just reflected an assumption baked into the vendor’s workload that couldn’t be changed without breaking it. Granting an exception because the deployment failed isn’t the same as confirming the exception is actually safe; each one had to be justified against what the workload was observed to actually need, not just what made the errors go away. That balance is still imperfect; some friction remains where the vendor’s requirements don’t cleanly align with the organization’s standard Kubernetes controls, and that’s an open thread rather than a fully closed one.

Security With Limited Vendor Guidance to Work From

Most Kubernetes deployments of a commercial product come with at least some vendor security guidance to start from. This one had general AKS security practices to draw on, but nothing specific to how this product’s pods, network access, and secrets handling should actually be locked down. Hardening the deployment meant applying Kubernetes security concepts directly to a workload whose vendor hadn’t documented how they applied.

Bridging a New Platform to Old Systems

The databases and data warehouse this agent needed to reach existed long before this project did, with their own networking assumptions. Getting reliable connectivity from pods running in AKS to those systems, and now to Databricks as that integration progresses, meant troubleshooting real network paths between a brand-new platform and infrastructure that was never designed with Kubernetes in mind.

Results

• Migrated off an end-of-support Windows deployment onto Azure Kubernetes Service before the loss of support became an operational problem.
• Chose a managed Kubernetes platform over the vendor’s bare-metal recommendation, avoiding the ongoing burden of physical Kubernetes infrastructure.
• Diagnosed an undocumented ARM64 compatibility limitation in the vendor’s own product, not identified during initial vendor support troubleshooting, and worked with the vendor to establish a supported x86-64 configuration, after roughly a month of joint troubleshooting.
• Built scoped Azure Policy exceptions that let a workload the organization’s existing controls hadn’t anticipated run under governance without broadly disabling enforcement.
• Independently developed Kubernetes security hardening for the deployment where vendor-specific guidance was limited.
• Connected the data governance catalog to roughly a dozen internal data sources, including the data warehouse, with Databricks integration currently in progress.
• Integrated Azure Key Vault so the agent’s connection secrets are managed outside the cluster rather than embedded in deployment configuration, and took on ongoing platform operation, deliberate AKS version promotion and manual updates to core components standard patching doesn’t reach, rather than letting the cluster drift.
• Remediated findings from an independent security audit that went beyond what Microsoft Defender for Cloud’s own recommendations had already covered.
• The deployment is stable and running in production today, meeting the team’s current requirements.

Technologies

Kubernetes & Compute

Azure Kubernetes Service, ARM64/x86-64 node architecture troubleshooting, Kubernetes security hardening, AKS version lifecycle management

Governance & Policy

Azure Policy for Kubernetes (scoped exceptions for third-party workload requirements), security audit remediation

Identity & Secrets

Azure Key Vault

Data Connectivity

Data governance catalog connectivity agent (vendor product, genericized), internal database and data warehouse connectivity, Databricks integration (in progress)