Open Connector
Protect an Infra service with Guard

Protect an Infra service with Guard

Link an Infra application to Guard inventory, admit its protected traffic path, and confirm both security and origin health.

Use Connector to associate an Infra application with its Guard security records. Complete Guard traffic onboarding separately to protect the application. A resource mapping provides context; admitted routing provides traffic inspection.

Before you begin

You need the following resources and authority:

  • An Infra–Guard connection shares inventory for the application's project and security summaries for its mapped Guard assets.
  • The application has a reachable origin on an Infra droplet or public load balancer, and you have authority to configure its network path.
  • A Guard service asset represents the application, and you have Guard Administrator authority for that asset's group.
  • You control the application's domain or approved address range and can complete Guard's ownership challenge.

Associate the application records

  1. In Infra, open the application's droplet or load balancer details. Record its resource ID, origin address, listener port, and application hostname.
  2. In Connector, map the Infra resource to the Guard service asset.
  3. In Connection → Resources, follow the mapping's Guard link. Confirm the asset locator identifies the intended application before starting onboarding.

For example, store.example.com can use an Infra public load balancer as its origin and a Guard service asset as its security inventory record. The mapping associates their IDs without changing DNS or the origin listener.

Admit the protected traffic path

  1. In Guard, follow Prepare a service to create a protected service for the mapped asset. Complete ownership, origin health, TLS, and policy checks.
  2. For self-hosted Guard, complete DDoS Connector enrollment and confirm edge readiness. The product connection does not replace this enrollment.
  3. Follow Cut over and verify to test the edge ingress, change DNS or routing, and confirm traffic at both ends.
  4. In Guard Service → Traffic, confirm edge observations for a benign test request. In Infra, confirm the origin remains healthy and receives that request.
  5. In Connector Connection → Activity, confirm the next security-summary synchronization identifies the mapped asset and its source protection state.

If the origin is healthy but Guard records no traffic, inspect DNS or routing through the Guard cutover procedure. If Connector displays an earlier observation, inspect synchronization without withdrawing a working traffic route.

Investigate an affected workload

  1. In Connection → Resources, open the affected mapping and follow its source finding or incident reference in Guard.
  2. In Guard, inspect the finding, incident evidence, and approved response state. Use response actions for containment.
  3. To change the workload, follow the mapped Infra resource and use its authorized lifecycle workflow. Inspect the Infra operation's terminal result.
  4. In Guard, confirm the response result and affected asset state. In Connector Activity, confirm a subsequent exchange carries the updated source references.

An incident closure does not release isolation. A successful infrastructure operation does not establish that Guard has acknowledged a response action. Record both product results when closing the investigation.