Cài đặt OPA Gatekeeper trong cụm Kubernetes
Triển khai OPA Gatekeeper bằng Helm để thiết lập controller thực thi chính sách và webhook server trong cluster.
Tại sao: Gatekeeper cần được cài đặt như một Kubernetes Controller để intercept các yêu cầu Admission, cho phép chặn hoặc sửa đổi tài nguyên trước khi tạo.
Kết quả mong đợi: Namespace gatekeeper-system được tạo, các Pod gatekeeper-audit, gatekeeper-controller-manager và gatekeeper-webhook ở trạng thái Running.
helm repo add open-policy-agent https://open-policy-agent.github.io/gatekeeper/charts
helm install gatekeeper open-policy-agent/gatekeeper --namespace gatekeeper-system --create-namespace --set installCRDs=true
Verify kết quả bằng cách kiểm tra trạng thái của các Pod trong namespace gatekeeper-system.
kubectl get pods -n gatekeeper-system
Viết ConstraintTemplate để chặn Workload không tuân thủ
Tạo file định nghĩa ConstraintTemplate để mô tả logic kiểm tra: cấm Pod chạy với quyền privileged và yêu cầu Image phải có Signature hợp lệ.
Tại sao: ConstraintTemplate là bản thiết kế chung (template) của chính sách, sử dụng ngôn ngữ Rego để xác định các điều kiện cần kiểm tra trên tài nguyên Kubernetes.
Kết quả mong đợi: Resource ConstraintTemplate được tạo thành công và hiển thị trong danh sách kubectl get constrainttemplates.
Đường dẫn file: /opt/opa-policies/secure-workload-template.yaml
Nội dung file hoàn chỉnh:
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
name: k8ssecureworkload
annotations:
description: "Enforce no privileged containers and required image signature."
spec:
crd:
spec:
names:
kind: K8sSecureWorkload
validation:
# Schema cho các tham số của Constraint
openAPIV3Schema:
type: object
properties:
allowedImages:
type: array
items:
type: string
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8ssecureworkload
# Chặn nếu container chạy với privileged: true
deny[msg] {
container := input.review.object.spec.containers[_]
container.securityContext.privileged == true
msg := sprintf("Container %v is running with privileged mode enabled", [container.name])
}
# Chặn nếu image không nằm trong danh sách cho phép (mô phỏng image signature check)
deny[msg] {
container := input.review.object.spec.containers[_]
not allowed_image(container.image)
msg := sprintf("Image %v is not signed or not in allowed list", [container.image])
}
allowed_image(image) {
input.parameters.allowedImages[_] == image
}
Áp dụng template vào cluster.
kubectl apply -f /opt/opa-policies/secure-workload-template.yaml
Verify kết quả: Kiểm tra xem template đã được tạo chưa.
kubectl get constrainttemplate k8ssecureworkload -o yaml
Cấu hình Constraint để áp dụng chính sách cho từng Tenant
Viết file Constraint cụ thể để áp dụng template K8sSecureWorkload cho Namespace tenant-a với danh sách image được phép.
Tại sao: Constraint là thể hiện cụ thể của Template, cho phép ta cấu hình tham số (parameters) khác nhau cho từng Tenant (ví dụ: Tenant A dùng Docker Hub, Tenant B dùng Harbor).
Kết quả mong đợi: Constraint K8sSecureWorkload được tạo và Gatekeeper bắt đầu kiểm tra các Pod trong namespace tenant-a.
Đường dẫn file: /opt/opa-policies/tenant-a-constraint.yaml
Nội dung file hoàn chỉnh:
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sSecureWorkload
metadata:
name: tenant-a-policy
namespace: gatekeeper-system
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
namespaces:
- tenant-a
parameters:
allowedImages:
- "docker.io/library/nginx:1.25"
- "gcr.io/my-tenant-a-app/backend:v1.0"
Áp dụng constraint cho Tenant A.
kubectl apply -f /opt/opa-policies/tenant-a-constraint.yaml
Test chính sách: Tạo một Pod vi phạm (privileged=true) trong tenant-a để xem Gatekeeper chặn.
kubectl run bad-pod --image=nginx:latest --security-context="privileged=true" -n tenant-a
Verify kết quả: Lệnh trên sẽ thất bại và trả về lỗi từ Admission Webhook.
kubectl describe pod bad-pod -n tenant-a
Kiểm tra audit log của Gatekeeper để xem chi tiết vi phạm.
kubectl logs -n gatekeeper-system -l app=gatekeeper-audit --tail=50
Tích hợp OPA với Iceberg Catalog để kiểm soát quyền truy cập Metadata
Cấu hình Constraint riêng để chặn việc tạo ConfigMap chứa thông tin nhạy cảm (như AWS Access Key, JDBC URL) trong các namespace tenant, đảm bảo an toàn cho Iceberg Catalog.
Tại sao: Iceberg Catalog thường lưu trữ metadata cấu hình (REST/SQL endpoint, credentials). Nếu tenant tự ý tạo ConfigMap chứa secret này, nó có thể bị đánh cắp. OPA sẽ chặn việc tạo ConfigMap có label hoặc key cụ thể.
Kết quả mong đợi: Tenant không thể tạo ConfigMap chứa key iceberg-credentials hoặc jdbc-url.
Đường dẫn file: /opt/opa-policies/iceberg-metadata-protection.yaml
Nội dung file hoàn chỉnh (ConstraintTemplate mới):
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
name: icebergmetadataprotection
spec:
crd:
spec:
names:
kind: IcebergMetadataProtection
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package icebergmetadataprotection
# Chặn ConfigMap chứa các key nhạy cảm liên quan đến Iceberg Catalog
deny[msg] {
key := input.review.object.data[_]
contains(key, "iceberg-") or contains(key, "jdbc-") or contains(key, "aws_secret_access_key")
msg := sprintf("ConfigMap contains sensitive Iceberg metadata key: %v", [key])
}
Áp dụng Template mới.
kubectl apply -f /opt/opa-policies/iceberg-metadata-protection.yaml
Tạo Constraint áp dụng cho tất cả các tenant (hoặc tenant cụ thể) để bảo vệ metadata.
cat
Test chính sách: Thử tạo ConfigMap chứa thông tin JDBC URL của Iceberg Catalog trong tenant-a.
kubectl create configmap iceberg-catalog-config --from-literal="jdbc-url=jdbc:postgresql://db:5432/iceberg" -n tenant-a
Verify kết quả: Lệnh tạo ConfigMap bị chặn. Kiểm tra sự cố bằng describe.
kubectl describe configmap iceberg-catalog-config -n tenant-a
Kiểm tra xem Pod hợp lệ (không chứa key nhạy cảm) vẫn được tạo.
kubectl create configmap safe-config --from-literal="app-name=my-app" -n tenant-a
Điều hướng series:
Mục lục: Series: Series: Xây dựng nền tảng Secure Multi-Tenant Data Platform với Kubernetes, Falco, OPA và Apache Iceberg để bảo vệ dữ liệu doanh nghiệp trong môi trường chia sẻ tài nguyên
« Phần 3: Xây dựng nền tảng dữ liệu Apache Iceberg với cơ chế chia sẻ an toàn
Phần 5: Cấu hình Falco để phát hiện xâm nhập và hành vi bất thường thời gian thực »