Moving a database behind a private endpoint does not stop an overprivileged application from reading it. Replacing passwords with workload identities does not stop a compromised service from using its legitimate permissions. A practical zero-trust design must constrain identity, network reachability, and data authorization together.
This reference design assumes a public API, internal services, and a protected data tier across AWS or Azure. Its objective is to reduce the reach of one compromised workload. It does not promise to eliminate every cloud misconfiguration. The examples describe implementation patterns, not results from an undisclosed client engagement.
1. Draw the authorization boundaries before the network
Create a flow inventory with five fields: caller identity, destination, operation, data classification, and business owner. Replace entries such as “application accesses storage” with “invoice worker reads objects under the incoming prefix and writes processed output.” Separate production, development, security logging, and recovery administration into appropriately governed accounts or subscriptions.
For each flow, decide what happens if the source is compromised. Can it enumerate unrelated secrets, assume a stronger role, reach the backup console, or change its own network policy? If the workload can modify its own safeguards, its effective privileges are larger than its business API permissions suggest.
2. Bind credentials to workloads and deployment boundaries
Use AWS role-based temporary credentials and Azure managed identities or supported workload identity federation instead of embedding long-lived keys. Bind federation trust to the intended issuer, audience, and subject; a wildcard subject can let an unrelated repository or service account obtain production credentials.
Assign permissions by operation and resource. Separate data readers, data writers, deployers, and security administrators. A CI role that can deploy arbitrary code into a highly privileged workload may indirectly exercise that workload’s permissions. Review deployment authority alongside IAM assignments.
Before merging IAM changes, run IAM Access Analyzer policy validation. It can identify policy findings; a syntactically valid policy is not proof of least privilege. Compare permitted operations with the flow inventory and run both allowed and forbidden requests in a test account.
3. Remove unintended network paths
In AWS, separate public entry points from application and data tiers. Scope security-group rules to intended peers and ports where supported, and review outbound paths. Use suitable VPC endpoints for private service access, with endpoint and resource policies aligned to intended callers. Avoid broad endpoint restrictions until console, automation, replication, and service-to-service paths have been tested.
In Azure, provision the appropriate private endpoint, validate name resolution from each authorized network, then separately restrict the service’s public network access. A private endpoint alone does not necessarily disable public access. Verify the service-specific settings and DNS design against Azure Private Endpoint guidance.
Use a canary workload before changing shared DNS. Confirm both the resolved address and a real authenticated request. A successful DNS lookup proves neither the correct route nor authorization. Keep rollback for DNS and service-access settings separate so an incident can be diagnosed without opening the entire data layer.
4. Isolate microservices with explicit permitted flows
Kubernetes namespaces are useful organizational boundaries, but they do not automatically isolate traffic. The cluster network plugin must enforce NetworkPolicy. Policies are additive: another broad allow policy can undermine a restrictive design. Standard NetworkPolicy operates mainly at the network and transport layers; it does not validate business requests or provide TLS. See the Kubernetes NetworkPolicy documentation.
In a staging namespace, begin with default denial. This example deliberately blocks ingress and egress; deploy the required allow rules as part of the same tested change before migrating workloads.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
namespace: payments
spec:
podSelector: {}
policyTypes:
- Ingress
- EgressAdd narrow allowances for the ingress controller to the API, API to worker where required, worker to the data service, DNS, and approved telemetry. The actual DNS selectors and paths depend on the cluster, including NodeLocal DNS or managed resolver behavior. Do not copy a generic DNS exception without confirming its destination.
Test from both authorized and unrelated pods. An API success test alone cannot prove segmentation. Where workload identity and encryption between services are required, configure supported mTLS and authorization controls as additional layers. Validate certificate rotation and failure behavior. An encrypted connection from an unauthorized service should still fail authorization.
5. Make the data layer enforce its own boundary
Constrain object prefixes, database roles, and secrets access independently of the network. Disable anonymous storage access where it is not a documented requirement. Separate key administrators from application operators, and record how an authorized recovery identity obtains decryption rights.
For shared databases, decide whether tenant separation is enforced by separate databases, schemas, or application predicates. Test cross-tenant reads using a dedicated test dataset. A private subnet cannot repair missing tenant authorization in an application query.
Log data-plane access where justified by risk and cost, as well as control-plane configuration changes. A control-plane trail may show who changed the bucket policy but not every object read. Set retention and alert ownership before declaring the data layer observable.
6. Prevent and detect configuration drift
Use deployment checks for public exposure, wildcard privileges, disabled logging, and missing encryption configuration. Combine preventive account or subscription guardrails with detective posture checks. Start new deny controls in a controlled scope; a blanket restriction may break managed services or recovery workflows.
Every exception needs a resource identifier, owner, reason, expiry, and test. Compare deployed resources against approved infrastructure definitions, investigate console changes, and verify whether a guardrail can be removed by the same role it is intended to constrain.
7. Produce an engineering evidence pack
For each boundary, preserve one successful authorized request and one failed unauthorized request. Record the caller, destination, time, result, and policy or enforcement point. Include DNS observations, effective access configuration, policy validation findings, and remediation ownership.
A useful completion criterion is that the public API works, the worker can access only its intended data, unrelated workloads fail the same request, and production operators cannot silently disable recovery safeguards. Review the design after every material identity or topology change. Explore Cloud Security consulting and our immutable backup engineering guide for the recovery boundary.