Securing Service Catalog with RBAC and OPA Gatekeeper

In modern cloud-native environments, managing access to resources and ensuring compliance with organizational policies is crucial. This blog post will delve into the technical details of securing a service catalog using Role-Based Access Control (RBAC) and Open Policy Agent (OPA) Gatekeeper.

Service Catalog Overview

A service catalog is a centralized repository that provides a single source of truth for all services offered by an organization. It enables users to discover, request, and manage services in a standardized manner. In a Kubernetes environment, the service catalog is typically implemented using the Open Service Broker API (OSBA).

Role-Based Access Control (RBAC)

RBAC is a widely adopted access control mechanism that restricts access to resources based on user roles. In Kubernetes, RBAC is implemented using roles, role bindings, and cluster roles. Roles define a set of permissions, while role bindings associate roles with users or groups. Cluster roles are used to define permissions at the cluster level.

To implement RBAC for the service catalog, we need to create roles and role bindings that define the permissions for users to access and manage services. For example:

# Role for service catalog administrators
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: service-catalog-admin
rules:
  - apiGroups: ["servicecatalog.k8s.io"]
    resources: ["clusterserviceclasses", "clusterserviceplans", "serviceinstances"]
    verbs: ["get", "list", "create", "update", "delete"]

# Role binding for service catalog administrators
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: service-catalog-admin-binding
roleRef:
  name: service-catalog-admin
  kind: Role
subjects:
  - kind: User
    name: admin-user
    apiGroup: rbac.authorization.k8s.io

Open Policy Agent (OPA) Gatekeeper

OPA Gatekeeper is a policy controller that enforces policies on Kubernetes resources. It provides a flexible and extensible way to define and manage policies. In the context of the service catalog, OPA Gatekeeper can be used to enforce policies on service instances and plans.

To integrate OPA Gatekeeper with the service catalog, we need to create a ConstraintTemplate that defines the policy rules. For example:

# Constraint template for service instance policies
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: service-instance-policy
spec:
  crd:
    spec:
      names:
        kind: ServiceInstance
      validation:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                plan:
                  type: string
                  pattern: ^[a-zA-Z0-9-]+$
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package serviceinstance

        deny[msg] {
          input.review.object.spec.plan != "standard"
          msg := "Only standard plans are allowed"
        }

This constraint template defines a policy that only allows service instances with the "standard" plan.

Integrating RBAC and OPA Gatekeeper

To integrate RBAC and OPA Gatekeeper, we need to create a ClusterConstraint that references the ConstraintTemplate and applies it to the service catalog resources. For example:

# Cluster constraint for service instance policies
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: ClusterConstraint
metadata:
  name: service-instance-policy
spec:
  match:
    kinds:
      - apiGroups: ["servicecatalog.k8s.io"]
        kinds: ["ServiceInstance"]
  parameters:
    target: admission.k8s.gatekeeper.sh
  constraintTemplate:
    name: service-instance-policy

This cluster constraint applies the service instance policy to all service instances in the cluster.

Conclusion

Securing a service catalog with RBAC and OPA Gatekeeper provides a robust access control mechanism that ensures compliance with organizational policies. By implementing roles, role bindings, and constraint templates, platform engineers can restrict access to resources and enforce policies on service instances and plans. This technical approach provides a scalable and flexible solution for managing access to resources in a Kubernetes environment.