Configure zero-trust for a new project
What you'll learn
SmoothGlue's zero-trust network is active by default — every new workload is deny-by-default until you explicitly permit traffic. In this tutorial you'll configure the network policy, service mesh authorization, and Keycloak role for a new application project so it can communicate with other platform services.
Before you begin
- A running SmoothGlue platform (any template)
- Console access with OrgAdmin or PlatformAdmin role
- The name of your application's Kubernetes namespace
What zero-trust means in SmoothGlue
Three layers enforce zero-trust:
| Layer | Tool | What it enforces |
|---|---|---|
| Network policy | Kyverno + Kubernetes NetworkPolicy | No pod-to-pod traffic unless explicitly allowed |
| Service mesh | Istio + mTLS | All inter-service traffic encrypted; AuthorizationPolicy controls service-to-service calls |
| Identity | Keycloak + AuthService | All external (user-facing) traffic requires authenticated session |
You configure all three through the Console. No kubectl required.
Step 1 — Create the project namespace
In the Console, navigate to Organizations → Projects → New Project. Enter:
- Project name: your app name (e.g.,
my-app) - Namespace:
my-app(auto-generated from name — change if needed) - Template: Standard (default)
Click Create Project. The Console provisions the namespace with default-deny NetworkPolicy and Istio sidecar injection enabled.
Step 2 — Define allowed ingress traffic
Navigate to Projects → my-app → Network Policy → Add Rule. You'll see two default rules already applied:
deny-all-ingress— blocks all inbound trafficallow-same-namespace— permits traffic within the same namespace
To allow traffic from ArgoCD (for GitOps sync), add:
- Rule type: Allow ingress
- From namespace:
argocd - Port: 8080 (or your app's port)
Click Apply. The Console writes a Kubernetes NetworkPolicy and Kyverno validates it against the STIG baseline.
Step 3 — Configure Istio AuthorizationPolicy
Navigate to Projects → my-app → Service Mesh → Authorization. By default, no service-to-service calls are permitted even within the namespace.
To allow your app to call the Vault agent sidecar for secret injection:
- Source:
my-app(your app's service account) - Target:
vault-agent(Vault sidecar service account) - Method: GET, POST
Click Save. Istio applies the AuthorizationPolicy — changes take effect within 30 seconds.
Step 4 — Assign the Keycloak role for external access
If your app has a user-facing endpoint (HTTP/HTTPS), AuthService enforces Keycloak authentication before any request reaches your pod.
Navigate to Projects → my-app → Access Control → Assign Roles:
- Role: OrgUser (allows all authenticated org members to access the app)
- Or create a custom role scoped to specific groups
Click Save. AuthService updates its configuration — external users will now see a Keycloak login page before reaching your app.
Step 5 — Verify
Attempt to reach your app:
curl -k https://my-app.<your-domain>
Without authentication: you receive 302 Found redirecting to https://keycloak.<your-domain>/auth.
With authentication (using a valid Keycloak token): you receive your app's response.
In the Console under Projects → my-app → Network Policy, the traffic graph shows only the permitted flows in green.
What you built
A fully zero-trust-enabled project namespace with:
- Default-deny network policy enforced by Kyverno
- mTLS between all services via Istio
- Keycloak authentication required for all external access
Next: Compliance pre-wiring →