> For the complete documentation index, see [llms.txt](https://docs.cloudeka.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cloudeka.ai/guidance-for-enterprise/service-limit/crds/cloudeka-guard.md).

# Cloudeka Guard

A **network policy (firewall rule)** for your namespace. `spec` is a standard Cilium policy rule (`endpointSelector`, `ingress`, `egress`, etc.) — the platform projects it into a real network policy object and keeps it in sync as you edit the guard.

```bash
kubectl get guard -n <your-namespace>
kubectl get guard -n <your-namespace> -o yaml
```

You can add this script.

```yaml
apiVersion: tenants.cloudeka.ai/v1alpha2
kind: CloudekaGuard
metadata:
  name: allow-frontend-to-backend
  namespace: <your-namespace>
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
```

```bash
kubectl apply -f my-guard.yaml
```

| Field                   | Meaning                                    |
| ----------------------- | ------------------------------------------ |
| `spec.endpointSelector` | Which Pods (by label) this rule applies to |
| `spec.ingress`          | Allowed inbound traffic rules              |
| `spec.egress`           | Allowed outbound traffic rules             |

{% hint style="info" %}
**Good To Know**

* By default (no guards), traffic within your namespace follows the VPC's default network policy. Add guards to tighten or open specific paths.
* Editing a guard's `spec` is picked up automatically and reflected in the live policy.
* Deleting a guard removes its policy cleanly — no manual cleanup needed.
  {% endhint %}