Security Internal Configuration¶

The Security Internal tab allows you to configure the TLS settings associated with the internal load balancer that exposes the agent to the applications and clients running inside your private network. This configuration is used by the agent installer when creating the internal ingress load balancer, and enables encrypted, secure communication between the agent and the individual applications that deliver business metrics to it — whether through the BizMetry Plugin deployed in the API Gateway, or directly via the BizMetry SDK.

To access this tab, open the Agent Configuration dialog and select Security Internal from the tab bar.

Ingress Architecture¶

The diagram below depicts the internal ingress architecture. The red lines represent the inbound traffic that flows from the BizMetry Plugin — deployed within the API Gateway — and from the BizMetry SDK — embedded in individual business applications — through the ingress load balancer, and into the agent Pod via the internal agent ingress.

Unlike the external certificate — which protects the communication between the BizMetry platform and the agent — the internal certificate secures the communication between the applications and the agent. It is applied to the internal agent ingress and encrypts all traffic end-to-end, from the instrumented applications all the way down into the agent Pod, ensuring that metric data remains protected within the boundaries of your private network.

Enabling Internal Exposure¶

When accessing this tab for the first time on a newly configured agent, the Internally Exposed toggle is off by default. While disabled, the agent cannot receive instrumentation data from applications or the BizMetry Plugin, which means no business metrics will be collected.

The first step is to enable this toggle. Once activated, the rest of the configuration form becomes visible.

Agent Deployment Topology¶

Once Internally Exposed is on, the Agent Deployment Topology choice determines how the interceptor (running inside your business application's cluster) reaches the agent — and how much of the rest of this tab you actually need to fill in.

Co-Located Topology is the recommended option whenever it's actually possible for your deployment — it needs no ingress hostname, no DNS entry, and no certificate to manage for this hop, and it's faster since traffic stays inside the cluster network. Selecting it hides the rest of this tab entirely: there is nothing left to configure.

Selecting Decentralized Topology brings back the Ingress Type, Agent Internal Address, key pair, and certificate chain sections below — complete those exactly as described in the rest of this page.

Ingress Type¶

When the agent runs in its own cluster, applications reach it through an ingress load balancer. The Ingress Type selector tells BizMetry which ingress controller is running in the target cluster, so that the installer can prepare the matching configuration.

BizMetry supports the following ingress controllers:

The field is required for a Decentralized agent: Save Changes stays disabled until an ingress type is selected.

Agent Internal Gateway Address¶

The Agent Internal Gateway Address is the private URL through which business applications reach the agent to deliver instrumentation data. It is typically a hostname resolvable via your organization's internal DNS, mapped to the ingress load balancer running inside the Kubernetes cluster.

This URL is strictly internal — it is only accessible from within your private network and is never exposed to the internet by design. BizMetry does not perform DNS validation on this field since the URL cannot be resolved from outside your infrastructure.

If you have already configured an address in the Security External tab, you can populate this field automatically by clicking Copy from External Gateway. This is useful in deployments where both the internal and external gateways share the same hostname.

Requirements¶

The URL provided here must satisfy all of the following conditions:

Internal-only reachability The endpoint must only be addressable from within the private network. It should not be reachable from the internet under any circumstances.

Internal DNS resolution The hostname must be registered in your organization's internal DNS and resolve to the private IP address of the ingress load balancer deployed in the target Kubernetes cluster.

Generating the Key Pair¶

Unlike the external configuration — where the TLS certificate is provided by an external load balancer already in place — the internal TLS key pair is generated directly by BizMetry. This simplifies the setup considerably, as there is no need to obtain or manage certificates from an external CA for internal traffic.

Once you have entered the internal gateway URL, click the Generate KeyPair button to trigger the key pair generation.

BizMetry will generate a public/private key pair scoped to the hostname you provided. Once generation completes, both the TLS Public Certificate Chain and the TLS Private Key sections are populated automatically.

The generated certificate chain is used by the agent installer when provisioning the internal agent ingress — the ingress is configured with a TLS binding that uses this exact key pair to encrypt all inbound traffic from instrumented applications.

Downloading the Certificate Chain¶

Once the key pair has been generated, the full certificate chain can be downloaded using the Download Certificate Chain button, visible in the TLS Public Certificate Chain section.

Clicking this button downloads the complete chain — including all certificates in the trust path as well as the private key — as a single PEM file to your local machine. This file can be handed off to DevOps for use during agent deployment or for manual ingress configuration if needed.

Configuration Flow Summary¶

For clarity, here is the recommended sequence for completing the internal security configuration:

1. Enable the Internally Exposed toggle.
2. Choose the Agent Deployment Topology that matches your deployment.
3. If Co-Located Topology — nothing else to do here; skip straight to step 6.
4. If Decentralized Topology — select the Ingress Type that matches the cluster's ingress controller, then coordinate with DevOps to provision a private hostname and register it in the internal DNS, and enter that internal gateway URL.
5. Click Generate KeyPair, wait for the certificate chain to be populated, and download the PEM file if needed for manual deployment steps.
6. Click Save Changes to persist the configuration. Because this tab shapes how the agent is installed, the agent then shows the Redeploy Required indicator: download a fresh installer and reinstall it (../breaking-vs-non-breaking-changes.md)).
7. Proceed to download the agent installer, which will embed this configuration automatically.

General Recommendations¶

Involve DevOps from the start¶

The only prerequisite that depends on DevOps for the internal configuration is having a private hostname provisioned and registered in the internal DNS. Unlike the external configuration, there is no need to set up TLS certificates on the load balancer side in advance — BizMetry handles key pair generation automatically. However, DevOps must ensure that the ingress load balancer is correctly deployed and reachable at the given address before the agent is installed.

Protecting the internal endpoint¶

Although the internal endpoint is not exposed to the internet — making it inherently less vulnerable than the external one — it is still accessible from within your private network. A security breach originating from inside the network, such as a compromised host or a lateral movement attack, could potentially reach the agent endpoint.

The agent's built-in security filter mitigates this risk by enforcing authentication and authorization on every inbound request, guaranteeing that:

• The caller belongs to the same account as the agent.
• The caller has sufficient permissions to perform the requested operation.
• The session token presented is valid and has not expired.

This ensures that even if an unauthorized party reaches the internal endpoint, they cannot interact with the agent or access the associated BizMetry account without valid credentials.

Related Topics¶

• Understanding Agent Deployment Topology
• Security External Configuration
• Deployment Configuration
• Tuning Configuration
• Downloading and Deploying an Agent
• Restarting an Agent