headlamp-sealed-secrets-plugin/docs/user-guide/rbac-permissions.md

RBAC Permissions Guide

Configure Role-Based Access Control for Sealed Secrets operations.

Overview

The Headlamp Sealed Secrets plugin integrates with Kubernetes RBAC to control:

• Who can view SealedSecrets
• Who can create SealedSecrets
• Who can delete SealedSecrets
• Who can view unsealed Secrets
• Who can download sealing certificates

The plugin automatically checks permissions and hides/disables UI elements based on your RBAC roles.

Required Permissions

Minimum Read-Only Access

To view sealed secrets in Headlamp:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: sealed-secrets-viewer
rules:
# View SealedSecrets
- apiGroups: ["bitnami.com"]
  resources: ["sealedsecrets"]
  verbs: ["get", "list"]

# View namespaces (for filtering)
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["list"]

What you can do:

• ✅ List all sealed secrets
• ✅ View sealed secret details
• ✅ See encrypted data (safe to view)
• ❌ Create new sealed secrets
• ❌ Delete sealed secrets
• ❌ View unsealed secret values

Creator Access

To create sealed secrets:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: sealed-secrets-creator
rules:
# Create and view SealedSecrets
- apiGroups: ["bitnami.com"]
  resources: ["sealedsecrets"]
  verbs: ["get", "list", "create"]

# Download sealing certificates
- apiGroups: [""]
  resources: ["services/proxy"]
  verbs: ["get"]
  resourceNames: ["sealed-secrets-controller"]

# Or direct service access
- apiGroups: [""]
  resources: ["services"]
  verbs: ["get"]
  resourceNames: ["sealed-secrets-controller"]

# View namespaces
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["list"]

What you can do:

• ✅ Everything from viewer role
• ✅ Create new sealed secrets
• ✅ Download sealing certificates
• ❌ Delete sealed secrets
• ❌ View unsealed secret values

Full Access

To have complete control over sealed secrets:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: sealed-secrets-admin
rules:
# Full SealedSecret access
- apiGroups: ["bitnami.com"]
  resources: ["sealedsecrets"]
  verbs: ["get", "list", "create", "update", "patch", "delete"]

# View unsealed Secrets
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]

# Access controller
- apiGroups: [""]
  resources: ["services", "services/proxy"]
  verbs: ["get"]

# View namespaces
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["list"]

What you can do:

• ✅ Everything from creator role
• ✅ Delete sealed secrets
• ✅ View unsealed secret values (decrypt)
• ✅ Update sealed secrets

Example RBAC Configurations

Example 1: Development Team (Namespace-Scoped)

Allow developers to manage sealed secrets in their namespace:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: dev-team-sealed-secrets
  namespace: development
rules:
- apiGroups: ["bitnami.com"]
  resources: ["sealedsecrets"]
  verbs: ["get", "list", "create", "delete"]

- apiGroups: [""]
  resources: ["services"]
  verbs: ["get"]
  resourceNames: ["sealed-secrets-controller"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-sealed-secrets
  namespace: development
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-team-sealed-secrets
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io

Example 2: Platform Team (Cluster-Wide)

Allow platform team to manage all sealed secrets:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: platform-sealed-secrets
rules:
- apiGroups: ["bitnami.com"]
  resources: ["sealedsecrets"]
  verbs: ["*"]

- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]

- apiGroups: [""]
  resources: ["services", "services/proxy"]
  verbs: ["get"]

- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["list"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: platform-sealed-secrets
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: platform-sealed-secrets
subjects:
- kind: Group
  name: platform-team
  apiGroup: rbac.authorization.k8s.io

Example 3: Read-Only Auditor

Allow security team to audit sealed secrets without modification:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: sealed-secrets-auditor
rules:
- apiGroups: ["bitnami.com"]
  resources: ["sealedsecrets"]
  verbs: ["get", "list"]

- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]

- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["list"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: security-team-auditor
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: sealed-secrets-auditor
subjects:
- kind: Group
  name: security-auditors
  apiGroup: rbac.authorization.k8s.io

Example 4: CI/CD Service Account

Allow automated systems to create sealed secrets:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ci-cd-sealed-secrets
  namespace: ci-cd

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ci-cd-sealed-secrets-creator
rules:
- apiGroups: ["bitnami.com"]
  resources: ["sealedsecrets"]
  verbs: ["create", "get", "list"]

- apiGroups: [""]
  resources: ["services"]
  verbs: ["get"]
  resourceNames: ["sealed-secrets-controller"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ci-cd-sealed-secrets
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ci-cd-sealed-secrets-creator
subjects:
- kind: ServiceAccount
  name: ci-cd-sealed-secrets
  namespace: ci-cd

Plugin UI Behavior

The plugin automatically adjusts the UI based on permissions:

With Full Permissions

• ✅ "Create Sealed Secret" button visible
• ✅ "Delete" button visible on details page
• ✅ "Decrypt" button visible (if Secret access granted)
• ✅ Download sealing certificates

With Read-Only Permissions

• ❌ "Create Sealed Secret" button hidden
• ❌ "Delete" button hidden/disabled
• ❌ "Decrypt" button hidden
• ❌ Download button hidden/disabled

Testing Permissions

The plugin uses Kubernetes SelfSubjectAccessReview to check permissions in real-time.

You can test manually:

# Check if you can create SealedSecrets
kubectl auth can-i create sealedsecrets.bitnami.com

# Check if you can list SealedSecrets
kubectl auth can-i list sealedsecrets.bitnami.com

# Check if you can view Secrets (for decryption)
kubectl auth can-i get secrets

# Check in specific namespace
kubectl auth can-i create sealedsecrets.bitnami.com -n production

Common Permission Issues

Issue 1: "Create Sealed Secret" Button Not Showing

Cause: Missing create permission for SealedSecrets.

Solution:

rules:
- apiGroups: ["bitnami.com"]
  resources: ["sealedsecrets"]
  verbs: ["create"]  # Add this verb

Issue 2: Cannot Download Sealing Certificates

Cause: Missing service access permission.

Solution:

rules:
- apiGroups: [""]
  resources: ["services"]
  verbs: ["get"]
  resourceNames: ["sealed-secrets-controller"]

Or for proxy access:

rules:
- apiGroups: [""]
  resources: ["services/proxy"]
  verbs: ["get", "create"]

Issue 3: "Decrypt" Button Not Showing

Cause: Missing get permission for Secrets.

Solution:

rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get"]  # Required for decryption

Issue 4: Cannot See SealedSecrets in Other Namespaces

Cause: Using Role instead of ClusterRole, or missing namespace list permission.

Solution: Use ClusterRole and ClusterRoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole  # Not Role
metadata:
  name: sealed-secrets-viewer
rules:
- apiGroups: ["bitnami.com"]
  resources: ["sealedsecrets"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["list"]  # Required

Security Best Practices

1. Principle of Least Privilege

Only grant the minimum permissions needed:

# Good: Namespace-scoped for dev team
kind: Role
metadata:
  namespace: dev-team-namespace

# Risky: Cluster-wide for dev team
kind: ClusterRole  # Only if truly needed

2. Separate Secret Access

Don't grant Secret access unless absolutely necessary:

# ✅ Good: Can create SealedSecrets but not view Secrets
- apiGroups: ["bitnami.com"]
  resources: ["sealedsecrets"]
  verbs: ["create"]

# ❌ Risky: Can view unsealed Secrets
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]  # Only for authorized users

3. Use Groups, Not Individual Users

# ✅ Good: Use groups
subjects:
- kind: Group
  name: developers

# ❌ Harder to maintain: Individual users
subjects:
- kind: User
  name: alice
- kind: User
  name: bob

4. Audit RBAC Changes

# List all ClusterRoleBindings for SealedSecrets
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name | contains("sealed-secrets"))'

# List all RoleBindings in a namespace
kubectl get rolebindings -n production -o yaml

Troubleshooting Commands

# 1. Check your current permissions
kubectl auth can-i --list

# 2. Check specific permission
kubectl auth can-i create sealedsecrets.bitnami.com -n production

# 3. Check as another user (requires admin)
kubectl auth can-i create sealedsecrets --as alice --as-group developers

# 4. View your roles
kubectl get rolebindings,clusterrolebindings --all-namespaces -o wide | grep $(kubectl auth whoami)

# 5. Describe a role
kubectl describe clusterrole sealed-secrets-creator

Next Steps

• Creating Secrets - Create your first sealed secret
• Scopes Explained - Understand security scopes
• Security Hardening - Production security guide

Resources

• Kubernetes RBAC Documentation
• SelfSubjectAccessReview API
• Best Practices for RBAC