Access

Remote Operator does not create access from nothing. It uses what the generated installation and the customer environment give it.

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.

Kubernetes permissionsCopy Anchor Link

Setup binds the operator's ServiceAccount to namespaced Roles. Every installation has the operator Role. The other two Roles exist only when the feature that needs them is on.

The operator RoleCopy Anchor Link

The operator Role has three groups of rules:

• list on Deployments, StatefulSets, DaemonSets, pods, events, and pod metrics (metrics.k8s.io). On every sync, the operator lists the workloads in its namespace, then the pods, recent events, and CPU and memory of each workload.
• The access-request custom resource: get, list, watch, create, update, and patch on the resource, and get, update, and patch on its status.
• The rules that each enabled operation declares. For example, kubernetes/get-pods declares list on pods, and kubernetes/restart-pod declares delete on pods.

The operator has no other access to workloads. It cannot get or watch a Deployment, and it cannot read ConfigMaps, Services, or Jobs, unless an enabled operation declares that rule.

An operation can declare get, list, and watch. The only writes it can declare are delete on pods and patch on the scale of a Deployment, StatefulSet, or ReplicaSet. Alien rejects any rule on Secrets. Setup installs the operator with remediation access, so the Role includes the declared writes.

In the template, a comment above each rule names the operation or the operator function that needs it.

The pod log RoleCopy Anchor Link

A second Role grants get on pods/log. The chart binds it only when the operator collects logs through the Kubernetes API, which is logCollector.mode: podApi with logCollector.enabled: true. A dedicated operator release uses this mode.

In nodeAgent mode, a Fluent Bit DaemonSet reads the log files on each node, and the chart does not create the pod log Role. The DaemonSet has its own ServiceAccount, which can get, list, and watch pods.

The dynamic container RoleCopy Anchor Link

When the operator is part of a product chart that Alien builds, a third Role grants get, list, create, update, and delete on Deployments, Services, and Secrets in the release namespace. The operator uses it for containers that the deployment owner requests through the API, and to suspend or delete those containers after a release withdraws an image approval.

A dedicated operator release never has this Role.

Review the permissions in setupCopy Anchor Link

In Choose operations, open Kubernetes requirements. The list shows the rules that the selected operations add, keep, and remove. Under them, it shows the permissions the operator always has, then the pod log and dynamic container permissions with the condition that binds each one. Permissions need an update shows the same list for an installed operator.

alien debug -- kubectl runs as the operator's ServiceAccount, so a debug session can do only what these Roles allow. See Remote debugging.

Cloud permissionsCopy Anchor Link

Cloud operations need a workload identity for the operator. The optional Connect cloud APIs step generates the Terraform or Pulumi configuration for it from the enabled operations.

• AWS. Enter Exact S3 bucket ARNs and Exact SQS queue ARNs when an enabled S3 or SQS operation reads a bucket, an object, or a queue. The generated policy limits those actions to the listed ARNs. Wildcards are rejected.
• Google Cloud. Enter Cloud Storage bucket names when a Cloud Storage operation is enabled. The operator gets storage.objects.list and storage.buckets.get on those buckets only, through a role bound to each bucket. The buckets must be in the same project as the operator's service account. Permissions for other Google Cloud operations, such as Compute Engine and Pub/Sub, apply to the whole project.
• Azure. Azure resource operations are not supported yet, so setup creates no Azure identity or role assignment.

If a required bucket or queue is missing, setup shows the compiler's error in place of the configuration. For Cloud Storage, the error is Google Cloud permission '<permission>' requires at least one installer-provided Cloud Storage bucket name.

To preview the same grants for a plugin before you install it, run alien operations permissions.

Review the generated templateCopy Anchor Link

Review the rendered manifest for the exact project configuration you are installing. The final permissions change with the selected operations and connections.

For either Kubernetes installation mode, download the unsplit byoc-operator.yaml from Review the Remote operator template and inspect it before installation:

# Find the operator's identity and every permission granted to it.
grep -nE 'kind: (ServiceAccount|Role|RoleBinding)|resources:|verbs:' byoc-operator.yaml

For a dedicated release, also inspect remote-operator/templates/byoc-operator.yaml in the downloaded chart. For a product release, inspect the manifest Helm installed after enabling the operator:

helm get manifest <release> --namespace <namespace> --kube-context '<context>' > rendered.yaml
grep -nE 'kind: (ServiceAccount|Role|RoleBinding)|resources:|verbs:' rendered.yaml

On Amazon ECS, PermissionReview lists the operation-specific task-role grants. Also inspect the task-role policy for access to existing EFS, or the filesystem policy for stack-created EFS identity storage:

jq '{operations: .Resources.OperatorTaskRole.Metadata.PermissionReview, taskRolePolicies: .Resources.OperatorTaskRole.Properties.Policies, createdEfsPolicy: .Resources.OperatorIdentityFileSystem.Properties.FileSystemPolicy}' 'remote-operator-<environment>-<project-id>.json'

Check an installationCopy Anchor Link

After installation on Kubernetes, ask the cluster about a permission every operator has:

kubectl --context '<context>' auth can-i list pods \
  --namespace my-product \
  --as system:serviceaccount:my-product:<service-account>

The answer is yes. Repeat the check for write actions. A yes should match an operation you enabled. For a dedicated operator release, get secrets and update deployments answer no.

The installation page also shows what Alien recorded. Open the installation under Deployments and find Identity and permissions. The section is read-only.

• For Kubernetes, it shows the Helm release, the namespace, and whether the ServiceAccount is bound to a namespaced Role or a ClusterRole.
• For Amazon ECS, it shows the AWS account, Region, and CloudFormation stack.
• Kubernetes RBAC rules and the AWS IAM and Google Cloud IAM lists show the grants that the enabled operations had when setup was issued or last re-applied. On an operator with diagnostics access, a rule that needs remediation access shows Not installed: needs remediation access.

The record shows what Alien issued. The cluster or the AWS account stays the source of truth. Select Print what is installed for a command that prints the ServiceAccount, Roles, and RoleBindings of the Helm release, or the IAM roles and policies of the stack.