کوبرنتیز برای احراز هویت از طریق TLS به گواهینامههای PKI نیاز دارد. اگر کوبرنتیز را با kubeadm نصب کنید، گواهینامههایی که کلاستر شما نیاز دارد به طور خودکار تولید میشوند. همچنین میتوانید گواهینامههای خودتان را تولید کنید -- به عنوان مثال، برای ایمنتر نگه داشتن کلیدهای خصوصی خود با ذخیره نکردن آنها در سرور API. این صفحه گواهینامههایی را که کلاستر شما نیاز دارد توضیح میدهد.
کوبرنتیز برای عملیاتهای زیر به PKI نیاز دارد:
برای ایجاد یک اتصال امن و احراز هویت خود به kubelet، سرور API به یک گواهی کلاینت و جفت کلید نیاز دارد.
در این سناریو، دو رویکرد برای استفاده از گواهی وجود دارد:
گواهیهای مشترک: kube-apiserver میتواند از همان گواهی و جفت کلید مورد استفاده خود برای احراز هویت کلاینتهای خود استفاده کند. این بدان معناست که گواهیهای موجود، مانند apiserver.crt و apiserver.key، میتوانند برای ارتباط با سرورهای kubelet استفاده شوند.
گواهیهای جداگانه: به عنوان یک جایگزین، kube-apiserver میتواند یک گواهی کلاینت و جفت کلید جدید برای احراز هویت ارتباط خود با سرورهای kubelet ایجاد کند. در این حالت، یک گواهی مجزا به نام kubelet-client.crt و کلید خصوصی مربوطه آن، kubelet-client.key ایجاد میشوند.
front-proxy فقط در صورتی لازم هستند که kube-proxy را برای پشتیبانی از افزونه سرور API اجرا کنید.etcd همچنین TLS متقابل را برای احراز هویت کلاینتها و نظیرها پیادهسازی میکند.
اگر کوبرنتیز را با kubeadm نصب کنید، بیشتر گواهینامهها در /etc/kubernetes/pki ذخیره میشوند.
تمام مسیرهای موجود در این مستندات به آن پوشه مربوط میشوند، به استثنای گواهینامههای حساب کاربری که kubeadm آنها را در /etc/kubernetes قرار میدهد.
اگر نمیخواهید kubeadm گواهیهای مورد نیاز را تولید کند، میتوانید آنها را با استفاده از یک CA ریشه واحد یا با ارائه همه گواهیها ایجاد کنید. برای جزئیات بیشتر در مورد ایجاد مرجع صدور گواهی خود، به گواهینامهها مراجعه کنید. برای اطلاعات بیشتر در مورد مدیریت گواهیها، به مدیریت گواهینامه با kubeadm مراجعه کنید.
شما میتوانید یک root CA واحد ایجاد کنید که توسط یک مدیر کنترل میشود. این root CA میتواند چندین CA میانی ایجاد کند و تمام مراحل ایجاد بیشتر را به خود کوبرنتیز واگذار کند.
CA های مورد نیاز:
| Path | Default CN | Description |
|---|---|---|
| ca.crt,key | kubernetes-ca | مرجع گواهی عمومی کوبرنتیز |
| etcd/ca.crt,key | etcd-ca | برای تمامی توابع مرتبط با etcd |
| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | برای پراکسی front-end |
علاوه بر CA های فوق، دریافت یک جفت کلید عمومی/خصوصی برای مدیریت حساب سرویس، sa.key و sa.pub نیز ضروری است.
مثال زیر کلید CA و فایلهای گواهی نشان داده شده در جدول قبلی را نشان میدهد:
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key
اگر نمیخواهید کلیدهای خصوصی CA را در کلاستر خود کپی کنید، میتوانید خودتان تمام گواهینامهها را تولید کنید.
گواهینامههای مورد نیاز:
| Default CN | Parent CA | O (in Subject) | kind | hosts (SAN) |
|---|---|---|---|---|
| kube-etcd | etcd-ca | server, client | <hostname>, <Host_IP>, localhost, 127.0.0.1 |
|
| kube-etcd-peer | etcd-ca | server, client | <hostname>, <Host_IP>, localhost, 127.0.0.1 |
|
| kube-etcd-healthcheck-client | etcd-ca | client | ||
| kube-apiserver-etcd-client | etcd-ca | client | ||
| kube-apiserver | kubernetes-ca | server | <hostname>, <Host_IP>, <advertise_IP>1 |
|
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | |
| front-proxy-client | kubernetes-front-proxy-ca | client |
system:masters برای kube-apiserver-kubelet-client، میتوان از یک گروه با امتیاز کمتر استفاده کرد. kubeadm برای این منظور از گروه kubeadm:cluster-admins استفاده میکند.| kind | Key usage |
|---|---|
| server | digital signature, key encipherment, server auth |
| client | digital signature, key encipherment, client auth |
فقط برای کاربران kubeadm:
سناریویی که در آن شما گواهیهای CA کلاستر خود را بدون کلیدهای خصوصی رونوشت میگیرید، در مستندات kubeadm به عنوان CA خارجی شناخته میشود.
اگر فهرست بالا را با PKI تولید شده توسط kubeadm مقایسه میکنید، لطفاً توجه داشته باشید که گواهیهای kube-etcd، kube-etcd-peer و kube-etcd-healthcheck-client در صورت etcd خارجی تولید نمیشوند.
گواهیها باید در یک مسیر پیشنهادی قرار گیرند (مطابق با مسیری که kubeadm استفاده میکند). مسیرها باید با استفاده از آرگومان داده شده، صرف نظر از مکان، مشخص شوند.
| DefaultCN | recommendedkeypath | recommendedcertpath | command | keyargument | certargument |
|---|---|---|---|---|---|
| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | --etcd-cafile | |
| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile |
| kubernetes-ca | ca.key | ca.crt | kube-apiserver | --client-ca-file | |
| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file,--root-ca-file,--cluster-signing-cert-file |
| kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file |
| kube-apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt | kube-apiserver | --kubelet-client-key | --kubelet-client-certificate |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | --requestheader-client-ca-file | |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | --requestheader-client-ca-file | |
| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file |
| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | --trusted-ca-file,--peer-trusted-ca-file | |
| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file |
| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file |
| etcd-ca | etcd/ca.crt | etcdctl | --cacert | ||
| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert |
ملاحظات مشابهی برای جفت کلید service account اعمال میشود:
| private key path | public key path | command | argument |
|---|---|---|---|
| sa.key | kube-controller-manager | --service-account-private-key-file | |
| sa.pub | kube-apiserver | --service-account-key-file |
مثال زیر مسیرهای فایل از جداول قبلی را نشان میدهد که در صورت تولید تمام کلیدها و گواهیهای خودتان، باید ارائه دهید:
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub
شما باید این حسابهای کاربری مدیر و حسابهای کاربری سرویس را به صورت دستی پیکربندی کنید:
| Filename | Credential name | Default CN | O (in Subject) |
|---|---|---|---|
| admin.conf | default-admin | kubernetes-admin | <admin-group> |
| super-admin.conf | default-super-admin | kubernetes-super-admin | system:masters |
| kubelet.conf | default-auth | system:node:<nodeName> (see note) |
system:nodes |
| controller-manager.conf | default-controller-manager | system:kube-controller-manager | |
| scheduler.conf | default-scheduler | system:kube-scheduler |
<nodeName> برای kubelet.conf باید دقیقاً با مقدار نام گره ارائه شده توسط kubelet هنگام ثبت نام در apiserver مطابقت داشته باشد. برای جزئیات بیشتر، مجوز گره را مطالعه کنید.در مثال بالا، <admin-group> مختص پیادهسازی است. برخی ابزارها گواهی موجود در فایل پیشفرض admin.conf را امضا میکنند تا بخشی از گروه system:masters باشد. system:masters یک گروه کاربر ویژه (super user group) است که میتواند لایه مجوز کوبرنتیز مانند RBAC را دور بزند. همچنین برخی ابزارها یک super-admin.conf جداگانه با گواهی متصل به این گروه کاربر ویژه ایجاد نمیکنند.
kubeadm دو گواهی مدیر جداگانه در فایلهای kubeconfig ایجاد میکند.
یکی در admin.conf است و دارای Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin است.
kubeadm:cluster-admins یک گروه سفارشی است که به ClusterRole cluster-admin متصل است.
این فایل در تمام ماشینهای control plane مدیریتشده kubeadm ایجاد میشود.
یکی دیگر در super-admin.conf است که دارای Subject: O = system:masters, CN = kubernetes-super-admin است.
این فایل فقط در گرهای که kubeadm init در آن فراخوانی شده است، ایجاد میشود.
برای هر پیکربندی، یک جفت گواهی/کلید x509 با نام مشترک (CN) و سازمان (O) داده شده ایجاد کنید.
برای هر پیکربندی، kubectl را به صورت زیر اجرا کنید:
KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
KUBECONFIG=<filename> kubectl config use-context default-system
این فایلها به صورت زیر استفاده میشوند:
| Filename | Command | Comment |
|---|---|---|
| admin.conf | kubectl | کاربر مدیر را برای کلاستر پیکربندی میکند. |
| super-admin.conf | kubectl | کاربر ابرمدیر را برای کلاستر پیکربندی میکند. |
| kubelet.conf | kubelet | برای هر گره در کلاستر، یک مورد الزامی است. |
| controller-manager.conf | kube-controller-manager | باید به فایل پیکربندی موجود در manifests/kube-controller-manager.yaml اضافه شود. |
| scheduler.conf | kube-scheduler | باید به فایل پیکربندی موجود در manifests/kube-scheduler.yaml اضافه شود. |
فایلهای زیر مسیرهای کامل فایلهای فهرستشده در جدول قبلی را نشان میدهند:
/etc/kubernetes/admin.conf
/etc/kubernetes/super-admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf
هر IP یا نام DNS دیگری که با کلاستر خود با آن ارتباط برقرار میکنید (همانطور که توسط kubeadm استفاده میشود، IP و/یا نام DNS پایدار متعادلکننده بار، kubernetes، kubernetes.default، kubernetes.default.svc، kubernetes.default.svc.cluster، kubernetes.default.svc.cluster.local)
که در آن kind به یک یا چند مورد از کاربردهای کلید x509 نگاشت میشود، که در .spec.usages از یک CertificateSigningRequest نیز مستند شده است: ↩︎