Access
Remote Operator does not create access from nothing. It uses what the generated installation and the customer environment give it.
| Access | Where it comes from | What to review |
|---|---|---|
| Kubernetes | ServiceAccount and namespace-scoped RBAC | Resources, verbs, and namespace |
| Cloud | Workload identity or configured cloud connection | IAM role and actions |
| Private services | Network path and service connection | Destination, credential, and allowed operations |
| Alien | Per-installation registration values | Storage, rotation, and reuse |
| Logs | Generated collector configuration | Selected workloads and data leaving the cluster |
The current operator initiates outbound connections. You do not need to expose an inbound Kubernetes service for Alien.
Network access and identity are separate. A pod may be able to reach a database but still lack a valid credential, or have a credential but no network route.
Review the rendered manifest for the exact project configuration you are installing. The docs cannot tell you the final permissions because they change with selected operations and connections.
Render the chart before installation and inspect the generated objects:
helm template my-product ./chart --namespace my-product > rendered.yaml
# Find the operator's identity and every permission granted to it.
grep -nE 'kind: (ServiceAccount|Role|RoleBinding)|resources:|verbs:' rendered.yamlThen ask Kubernetes about a permission you expect to be read-only:
kubectl auth can-i get pods \
--namespace my-product \
--as system:serviceaccount:my-product:<service-account>Repeat that check for write actions. A result of yes should correspond to an operation you intentionally enabled.