Điểm:0

Chứng chỉ gốc tùy chỉnh cho tệp kubeconfig

lá cờ jp

Đang chạy giai đoạn kubeadm init certs apiserver --config kubeadm.yaml

Có thể sử dụng nhiều/chứng chỉ gốc tùy chỉnh cho nhóm người dùng/tệp kubectl/config không?

Tôi hỏi bởi vì, tôi muốn cấp quyền truy cập, trên cơ sở từng dự án - và sau đó xóa chứng chỉ gốc tùy chỉnh - nhưng giữ chứng chỉ gốc "gốc" cho quản trị viên kubectl đặc biệt.

Tôi đã thấy rằng bạn có thể sử dụng đường hầm ssh làm tuyến phòng thủ đầu tiên để bảo vệ khóa chung của chứng chỉ gốc.Nhưng bạn vẫn cần phân phối chứng chỉ được ký công khai, thậm chí nó nằm sau khóa riêng tư công khai ssh. Do đó, có thể có một cách xung quanh việc sử dụng đường hầm ssh - và đưa chứng chỉ tùy chỉnh vào chứng chỉDir: /etc/kubernetes/pki?

kubeadm.yaml

máy chủ api:
  phụArgs:
    chế độ ủy quyền: Nút, RBAC
  thời gian chờForControlPlane: 4m0s
phiên bản api: kubeadm.k8s.io/v1beta1
chứng chỉDir: /etc/kubernetes/pki

Tôi biết bạn có thể sử dụng --insecure-skip-tls-verify trong tệp cấu hình, nhưng có vẻ như đó là một ý tưởng tồi.

Điểm:1
lá cờ in

Có thể sử dụng nhiều/chứng chỉ gốc tùy chỉnh cho nhóm người dùng/tệp kubectl/config không?

Không, chỉ có một chứng chỉ "root", đó là lý do tại sao nó được gọi là root.

Tuy nhiên, x509 là một chuỗi đáng tin cậy, nghĩa là hoàn toàn có thể cấp các CA cấp dưới cho gốc đó, sau đó cấp chứng chỉ người dùng cho các CA đó, chọn loại bỏ các CA cấp dưới khi dự án kết thúc, điều này sẽ mồ côi tất cả các chứng chỉ lá đó. Xin lưu ý rằng theo hiểu biết tốt nhất của tôi, việc thay đổi chứng chỉ hoặc chuỗi của chúng yêu cầu khởi động lại mặt phẳng điều khiển, vì nó không tải lại nóng các tệp chứng chỉ đó. Tôi tin rằng có vấn đề về GitHub đối với nó, giống như tất cả 15.000 phần còn lại

Lựa chọn khác, tùy thuộc vào nhu cầu của bạn, là đưa ra các hợp đồng thuê ngắn hạn cho các chứng chỉ người dùng sao cho quy trình "thu hồi" không làm thay đổi quá nhiều chuỗi tin cậy x509 cũng như việc không thể cấp lại thông tin xác thực. Điều đó gần hơn với trường phái tư tưởng Hashicorp Vault và Let's Encrypt

Cá nhân tôi đã triển khai cái thứ 2 (sử dụng Vault), nhưng tôi tin rằng cái đầu tiên là khả thi vì apiserver sử dụng chuỗi x509 cho một số xác thực thành phần trong cụm của nó, vì vậy tôi không hiểu tại sao bạn không thể tận dụng lợi thế tương tự của cơ chế đó


Tôi biết đây không phải là những gì bạn đã hỏi, nhưng sử dụng x509 cho xác thực tạm thời như thế là con đường dẫn đến sự hủy hoại bởi vì -- như bạn đang gặp phải -- cả hai bên, phát hành và thu hồi, đều là một nỗi đau lớn. Nếu nó hoàn toàn có sẵn cho bạn, Cơ chế xác thực OIDC dễ dàng hơn nhiều để suy luận về và kubectl có ít nhiều hỗ trợ tích hợp cho nó

lá cờ jp
Cảm ơn bạn đã trả lời - Tôi nghĩ rằng tôi sẽ thực hiện theo đề xuất của bạn bằng OpenID (OIDC). Tôi sẽ cố gắng kết hợp https://github.com/micahhausler/k8s-oidc-helper này với github https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.