Runner Permissions

Properly configuring permissions for your runners is crucial for securing your environment while allowing agents to perform their intended tasks. This guide explains how to configure the right level of access for different scenarios.

Permission Models

Kubiya runners support multiple permission models to accommodate different security requirements:

Basic Access

The default permissions granted to a runner when first deployed. These permissions allow:

• Running containerized tools within the runner's namespace
• Basic Kubernetes API operations within its own namespace
• Connection to the Kubiya platform

Enhanced Kubernetes Access

For runners that need to manage Kubernetes resources outside their own namespace:

• Ability to create, modify, and delete resources across multiple namespaces
• Access to cluster-wide resources
• Permission to interact with core Kubernetes APIs

Cloud Provider Integration

For runners that manage cloud resources:

• Authentication to cloud provider APIs
• Permission to create, modify, and delete cloud resources
• Access to billing and usage information

Configuring Kubernetes Permissions

Depending on your use case, you'll need to configure different levels of access for your runners:

Namespace-Scoped Access

This is the default permission level, appropriate for most basic deployments:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kubiya-runner-role
  namespace: kubiya
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps", "secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets", "daemonsets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubiya-runner-rolebinding
  namespace: kubiya
subjects:
- kind: ServiceAccount
  name: kubiya-service-account
  namespace: kubiya
roleRef:
  kind: Role
  name: kubiya-runner-role
  apiGroup: rbac.authorization.k8s.io

Cluster-Wide Access

For Kubernetes management use cases, you'll need broader permissions:

# Full cluster admin - Use with caution
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubiya-sa-cluster-admin
subjects:
- kind: ServiceAccount
  name: kubiya-service-account
  namespace: kubiya
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

For more granular control, create a custom ClusterRole:

# Custom cluster role with limited permissions
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubiya-cluster-role
rules:
- apiGroups: [""]
  resources: ["namespaces", "nodes", "persistentvolumes"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets", "daemonsets"]
  verbs: ["get", "list", "watch", "create", "update", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubiya-cluster-rolebinding
subjects:
- kind: ServiceAccount
  name: kubiya-service-account
  namespace: kubiya
roleRef:
  kind: ClusterRole
  name: kubiya-cluster-role
  apiGroup: rbac.authorization.k8s.io

Cloud Provider Permissions

AWS Integration

To allow your runner to manage AWS resources:

# Annotate the service account with the IAM role ARN
kubectl annotate serviceaccount -n kubiya kubiya-service-account \
  eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/KubiyaRunnerRole

# Add the role to aws-auth ConfigMap
kubectl edit configmap -n kube-system aws-auth

mapRoles:
- rolearn: arn:aws:iam::123456789012:role/KubiyaRunnerRole
  username: system:serviceaccount:kubiya:kubiya-service-account
  groups:
  - system:serviceaccounts
  - system:serviceaccounts:kubiya

GCP Integration

For Google Cloud Platform:

kubectl create secret -n kubiya generic gcp-credentials \
  --from-file=key.json=/path/to/service-account-key.json

volumes:
- name: gcp-credentials
  secret:
    secretName: gcp-credentials
 
containers:
- name: kubiya-runner
  # ...
  volumeMounts:
  - name: gcp-credentials
    mountPath: /var/secrets/google
  env:
  - name: GOOGLE_APPLICATION_CREDENTIALS
    value: /var/secrets/google/key.json

Azure Integration

For Microsoft Azure:

kubectl create secret -n kubiya generic azure-credentials \
  --from-literal=AZURE_TENANT_ID=<tenant-id> \
  --from-literal=AZURE_CLIENT_ID=<client-id> \
  --from-literal=AZURE_CLIENT_SECRET=<client-secret>

containers:
- name: kubiya-runner
  # ...
  envFrom:
  - secretRef:
      name: azure-credentials

Enforcing Least Privilege

To maintain a secure environment, follow these practices:

1. Audit permissions regularly: Review the permissions granted to your runners to ensure they align with your security policies
2. Use dedicated roles: Create specific roles for each runner based on its intended purpose
3. Implement scope limitations: Restrict access to specific namespaces or resource types when possible
4. Enable logging: Configure comprehensive logging to track all operations performed by runners
5. Implement policy enforcement: Use Kubiya's Enforcer service to add additional access controls

Managing Permissions with Enforcer

The Enforcer service provides advanced permission management:

• JIT permissions: Grant temporary access for specific operations
• ABAC policies: Control access based on user attributes and context
• Policy-as-code: Define and version permission policies along with your infrastructure

Next Steps

• Set up a local runner with appropriate permissions
• Configure the Enforcer service for advanced permission management
• Implement security best practices for your Kubiya deployment