0

Bài 24. SecurityContext - Chạy Container an toàn hơn

Bạn đã bao giờ tự hỏi:

"Nếu ứng dụng của mình bị hacker khai thác thì sao?"

Điều đầu tiên kẻ tấn công thường làm là tìm cách chiếm quyền cao nhất (root) bên trong container. Nếu container được cấu hình quá "thoải mái", hậu quả có thể nghiêm trọng hơn bạn nghĩ.

Đó là lý do Kubernetes cung cấp SecurityContext.


1. SecurityContext là gì?

SecurityContext là nơi bạn khai báo container hoặc Pod được phép làm gì và không được phép làm gì.

Có thể hình dung như sau:

  • Container là một nhân viên.
  • SecurityContextnội quy của công ty.

Ví dụ:

  • Không được làm việc với quyền quản trị (root).
  • Không được chỉnh sửa hệ thống.
  • Chỉ được đọc file, không được ghi.
  • Không được nâng quyền.

Nhờ vậy, nếu ứng dụng bị tấn công thì thiệt hại cũng bị giới hạn.


2. Vì sao không nên chạy bằng quyền root?

Mặc định, nhiều Docker Image chạy bằng root.

Ví dụ:

Container
└── User: root

Nếu ứng dụng có lỗ hổng, kẻ tấn công cũng sẽ có quyền root trong container.

Thay vào đó, hãy chạy bằng một user thông thường:

Container
└── User: appuser (UID 1000)

Trong Kubernetes:

securityContext:
  runAsUser: 1000

3. Chỉ cho phép đọc hệ thống file

Nhiều ứng dụng chỉ cần đọc dữ liệu, không cần ghi vào filesystem.

Bạn có thể cấu hình:

securityContext:
  readOnlyRootFilesystem: true

Khi đó:

✅ Đọc file

❌ Ghi file

❌ Xóa file

❌ Sửa file hệ thống

Điều này giúp giảm đáng kể rủi ro nếu container bị khai thác.


4. Không cho phép nâng quyền

Một số chương trình có thể tự nâng quyền trong quá trình chạy.

Bạn có thể chặn điều này bằng:

securityContext:
  allowPrivilegeEscalation: false

Nói đơn giản:

"Bạn chỉ được dùng đúng quyền được cấp, không được tự ý xin thêm."


Một ví dụ hoàn chỉnh

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx
      securityContext:
        runAsUser: 1000
        readOnlyRootFilesystem: true
        allowPrivilegeEscalation: false

Container trên sẽ:

  • Chạy với user 1000
  • Không thể ghi vào filesystem gốc
  • Không được tự nâng quyền

Best Practices

Đối với hầu hết ứng dụng, hãy ưu tiên:

  • ✅ Không chạy bằng root
  • ✅ Tắt allowPrivilegeEscalation
  • ✅ Bật readOnlyRootFilesystem nếu ứng dụng không cần ghi dữ liệu
  • ✅ Chỉ cấp những quyền thực sự cần thiết

Một nguyên tắc quan trọng trong bảo mật là:

Least Privilege – Chỉ cấp đúng quyền cần thiết, không hơn.


Tổng kết

SecurityContext giúp container hoạt động an toàn hơn bằng cách giới hạn quyền của ứng dụng.

Chỉ với vài dòng cấu hình, bạn có thể:

  • Chạy ứng dụng bằng user thông thường.
  • Ngăn container tự nâng quyền.
  • Bảo vệ filesystem khỏi bị chỉnh sửa.
  • Giảm thiểu tác động nếu ứng dụng bị tấn công.

Đây là một bước nhỏ trong cấu hình, nhưng lại mang lại lợi ích rất lớn cho bảo mật của hệ thống.


Bài tiếp theo

Trong bài này, chúng ta đã giới hạn quyền của container.

Nhưng vẫn còn một câu hỏi:

"Làm thế nào để đảm bảo các Pod chỉ được giao tiếp với những Pod được phép?"

Đó chính là lúc NetworkPolicy phát huy tác dụng. Chúng ta sẽ khám phá nó trong bài tiếp theo.


All Rights Reserved

Viblo
Let's register a Viblo Account to get more interesting posts.