Xử lý xung đột chính sách giữa OPA Gatekeeper và Falco
Khi triển khai OPA Gatekeeper và Falco cùng lúc, bạn sẽ gặp tình huống OPA chặn việc tạo Pod ngay từ lúc Admission, trong khi Falco chỉ phát hiện hành vi bất thường sau khi Pod đã chạy. Điều này gây khó khăn trong việc xác định nguyên nhân gốc rễ khi một Pod bị từ chối hoặc bị giết.
Để xử lý, ta cần kiểm tra log của cả hai component để xác định thứ tự sự kiện: OPA chặn trước hay Falco phát hiện sau.
Đầu tiên, kiểm tra log của OPA Gatekeeper (thường chạy trong namespace gatekeeper-system) để xem constraint violation:
kubectl logs -n gatekeeper-system -l app=gatekeeper-audit | grep "ConstraintViolation" | tail -20
Kết quả mong đợi: Bạn sẽ thấy dòng log chỉ rõ Constraint nào (ví dụ: K8sDenyPrivilegedContainers) đã vi phạm và namespace nào bị ảnh hưởng.
Tiếp theo, kiểm tra log của Falco để xem có cảnh báo nào liên quan đến hành động tạo Pod đó không:
kubectl logs -n falco -l app=falco | grep "container.create" | grep -i "error\|denied\|blocked" | tail -20
Kết quả mong đợi: Nếu Pod bị OPA chặn, Falco sẽ không có log container.create thành công. Nếu có log Falco nhưng Pod bị kill, đó là Falco đã can thiệp sau khi Pod chạy.
Để tránh xung đột, hãy cấu hình OPA chỉ chặn các vi phạm nghiêm trọng (như Privileged mode) và để Falco cảnh báo các vi phạm hành vi (như chạy shell). Cập nhật ConstraintTemplate của OPA:
File config: /etc/opa/constraint-templates/privileged-container.yaml
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
name: k8sdenyprivilegedcontainers
spec:
crd:
spec:
names:
kind: K8sDenyPrivilegedContainers
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8sdenyprivilegedcontainers
violation[{"msg": msg}] {
container := input.review.object.spec.containers[_]
container.securityContext.privileged == true
msg := sprintf("Privileged containers are not allowed in %v namespace", [input.review.object.metadata.namespace])
}
violation[{"msg": msg}] {
container := input.review.object.spec.initContainers[_]
container.securityContext.privileged == true
msg := sprintf("Privileged initContainers are not allowed in %v namespace", [input.review.object.metadata.namespace])
}
Kết quả mong đợi: OPA sẽ chỉ chặn các Pod có container privileged, giảm tải cho Falco và tránh cảnh báo trùng lặp.
Để verify, cố gắng tạo một Pod privileged và kiểm tra log:
kubectl run test-privileged --image=nginx --privileged --dry-run=client -o yaml | kubectl apply -f -
Kết quả mong đợi: Pod bị từ chối ngay lập tức với thông báo admission webhook "validation.gatekeeper.sh" denied the request, không có log từ Falco về việc container chạy.
Tối ưu hiệu năng Iceberg Catalog với hàng trăm Tenants
Khi số lượng tenant tăng lên hàng trăm, Iceberg Catalog (đặc biệt là Hive Metastore hoặc REST Catalog) có thể gặp nghẽn cổ chai do số lượng metadata request quá lớn. Mỗi tenant có thể tạo nhiều bảng, dẫn đến hàng nghìn bảng trong một catalog.
Chiến lược tối ưu bao gồm: phân vùng catalog theo namespace, giới hạn số lượng bảng, và tăng cường cache.
Đầu tiên, cấu hình Iceberg REST Catalog để sử dụng cache metadata cho mỗi tenant. File config: /etc/iceberg/catalog/catalog.properties
warehouse=/data/iceberg/warehouse
catalog-impl=org.apache.iceberg.rest.RESTCatalog
uri=http://iceberg-rest-catalog:8181
token=your-static-token-here
# Tối ưu cache cho metadata
spark.sql.catalog.my_iceberg.catalog-type=rest
spark.sql.catalog.my_iceberg.uri=http://iceberg-rest-catalog:8181
spark.sql.catalog.my_iceberg.token=your-static-token-here
# Giới hạn cache time để giảm tải server
spark.sql.catalog.my_iceberg.cache-enabled=true
spark.sql.catalog.my_iceberg.cache-duration=300
Kết quả mong đợi: Các query metadata lặp lại sẽ được phục vụ từ cache, giảm thời gian response từ 200ms xuống dưới 50ms.
Tiếp theo, áp dụng Resource Quota trong Kubernetes để giới hạn số lượng bảng mỗi tenant có thể tạo. Điều này ngăn một tenant chiếm toàn bộ tài nguyên catalog.
File config: /etc/k8s/quota-per-tenant.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: iceberg-table-quota
namespace: tenant-alpha
spec:
hard:
# Giới hạn số lượng CustomResource (IcebergTable)
iceberg.apache.org/tables: "50"
# Giới hạn CPU và RAM cho Pod Iceberg
requests.cpu: "4"
requests.memory: "8Gi"
Kết quả mong đợi: Khi tenant-alpha cố gắng tạo bảng thứ 51, Kubernetes sẽ từ chối với lỗi exceeded quota.
Để tăng hiệu năng cho REST Catalog, hãy cấu hình JVM của server với bộ nhớ heap lớn hơn và tăng số lượng worker thread. File config: /etc/iceberg/rest-catalog/application.properties
spark.driver.memory=4g
spark.driver.cores=4
# Tăng số lượng thread cho REST API
spark.rest.server.httpThreadPoolSize=20
spark.rest.server.httpMaxThreads=50
# Tối ưu garbage collection
spark.driver.extraJavaOptions=-XX:+UseG1GC -XX:MaxGCPauseMillis=200
Kết quả mong đợi: REST Catalog xử lý đồng thời nhiều request metadata từ hàng trăm tenant mà không bị timeout.
Verify kết quả bằng cách chạy benchmark với 100 tenant, mỗi tenant tạo 10 bảng:
for i in $(seq 1 100); do kubectl run benchmark-$i --image=python:3.9 --restart=Never --rm -i -c "python -c 'import requests; requests.post(\"http://iceberg-rest-catalog:8181/v1/namespaces/tenant-$i/tables\")'"; done &
Kết quả mong đợi: Tất cả 1000 bảng được tạo thành công trong vòng 5 phút, không có lỗi 503 Service Unavailable.
Xử lý False Positive trong cảnh báo Falco
Falco thường báo False Positive khi phát hiện các hành vi bình thường của hệ thống (như container runtime, kubelet, hoặc các công cụ monitoring) bị nhầm lẫn là tấn công. Ví dụ: Falco báo "Container running in privileged mode" khi đó là container monitoring cần quyền đặc biệt.
Để xử lý, ta cần cấu hình rules.yaml của Falco để loại trừ (exclude) các namespace hoặc container cụ thể.
File config: /etc/falco/falco_rules.yaml (backup file gốc trước khi sửa)
### Program rules
- rule: Container running in privileged mode
desc: >
Detects when a container is running in privileged mode.
Privileged mode gives the container almost all capabilities of the host.
condition: >
(evt.type = container or evt.type = container_create) and
(container.privileged = true) and
(container.image != "prom/prometheus") and
(container.image != "grafana/grafana") and
(k8s.namespace.name != "kube-system") and
(k8s.namespace.name != "monitoring")
output: "Container running in privileged mode (user=%user.name container=%container.id image=%container.image k8s.namespace.name=%k8s.namespace.name pod=%k8s.pod.name)"
priority: WARNING
tags:
- container
- mitre_credential_access
- mitre_privilege_escalation
- rule: Shell spawned in container
desc: >
Detects when a shell is spawned in a container.
condition: >
(evt.type = execve or evt.type = clone) and
(container.id != "host") and
(proc.name in (bash, sh, ash, csh, ksh, zsh)) and
(container.image != "busybox") and
(k8s.namespace.name != "monitoring")
output: "Shell spawned in container (user=%user.name container=%container.id image=%container.image k8s.namespace.name=%k8s.namespace.name)"
priority: WARNING
tags:
- container
- mitre_discovery
Kết quả mong đợi: Falco sẽ không còn báo cảnh báo cho các container trong namespace monitoring hoặc kube-system, và không báo cho các image monitoring phổ biến.
Để loại trừ thêm các container cụ thể dựa trên label, sử dụng exclude trong condition:
### Example: Exclude specific pods
- rule: Shell spawned in container
condition: >
(evt.type = execve) and
(container.id != "host") and
(proc.name in (bash, sh, ash, csh, ksh, zsh)) and
(k8s.pod.annotations.security-monitoring != "enabled")
output: "Shell spawned in container (user=%user.name container=%container.id image=%container.image k8s.namespace.name=%k8s.namespace.name pod=%k8s.pod.name)"
priority: WARNING
tags:
- container
- mitre_discovery
Kết quả mong đợi: Các Pod có annotation security-monitoring: enabled sẽ bị loại trừ khỏi cảnh báo shell.
Reload Falco để áp dụng cấu hình mới:
kubectl exec -it -n falco falco -- falcoctl reload
Kết quả mong đợi: Falco restart và áp dụng rules mới. Kiểm tra log để đảm bảo không còn False Positive:
kubectl logs -n falco falco | grep "Container running in privileged mode" | grep "monitoring"
Kết quả mong đợi: Không có dòng log nào xuất hiện, chứng tỏ cảnh báo đã được loại trừ thành công.
Khắc phục sự cố mạng và quyền truy cập giữa các component
Trong kiến trúc Multi-Tenant, các component (Iceberg, OPA, Falco, Kubernetes API) cần giao tiếp qua mạng nội bộ. Sự cố mạng thường gặp bao gồm: Policy Network (NetworkPolicy) chặn kết nối, DNS resolution thất bại, hoặc Certificate mismatch.
Đầu tiên, kiểm tra NetworkPolicy trong namespace của các component. Đảm bảo cho phép traffic từ các service cần thiết.
File config: /etc/k8s/network-policy-allow-all.yaml (dùng cho troubleshooting, sau đó thu hẹp lại)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-traffic
namespace: monitoring
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector: {}
egress:
- to:
- namespaceSelector: {}
Kết quả mong đợi: Tất cả traffic trong namespace monitoring được cho phép, giúp xác định xem sự cố có do NetworkPolicy không.
Tiếp theo, kiểm tra DNS resolution từ Pod của Falco hoặc OPA đến Iceberg Catalog:
kubectl run dns-test --image=busybox --rm -it --restart=Never -- nslookup iceberg-rest-catalog.monitoring.svc.cluster.local
Kết quả mong đợi: Trả về IP address của service Iceberg. Nếu lỗi server can't find, kiểm tra CoreDNS.
Kiểm tra kết nối TCP từ Pod đến port của Iceberg Catalog:
kubectl run tcp-test --image=busybox --rm -it --restart=Never -- nc -vz iceberg-rest-catalog.monitoring.svc.cluster.local 8181
Kết quả mong đợi: succeeded! connected!. Nếu lỗi Connection refused, kiểm tra xem Pod Iceberg có đang chạy không.
Đối với sự cố chứng chỉ (Certificate), kiểm tra log của OPA hoặc Falco khi kết nối đến API server hoặc Iceberg:
kubectl logs -n gatekeeper-system gatekeeper-audit | grep "x509: certificate signed by unknown authority"
Kết quả mong đợi: Nếu thấy lỗi này, chứng chỉ CA của Iceberg hoặc API server chưa được thêm vào trust store của OPA/Falco.
Để khắc phục, thêm CA certificate vào ConfigMap và mount vào Pod:
File config: /etc/k8s/ca-cert-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: ca-certificates
namespace: monitoring
data:
ca.crt: |
-----BEGIN CERTIFICATE-----
MIID... (nội dung CA certificate)
-----END CERTIFICATE-----
Cập nhật deployment của OPA/Falco để mount ConfigMap này vào thư mục /etc/ssl/certs hoặc cấu hình SSL_CERT_FILE.
Verify kết quả bằng cách chạy lại command kiểm tra kết nối:
kubectl run verify-connect --image=busybox --rm -it --restart=Never -- openssl s_client -connect iceberg-rest-catalog.monitoring.svc.cluster.local:8181 -CAfile /etc/ssl/certs/ca.crt
Kết quả mong đợi: Verify return code: 0 (ok), chứng tỏ chứng chỉ đã được nhận diện đúng.
Đ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 8: Giám sát, Audit Log và báo cáo tuân thủ cho nền tảng Multi-Tenant