DigitalOceanKubernetesクラスターを保護するための推奨手順
序章
オープンソースのコンテナオーケストレーションプラットフォームであるKubernetesは、高可用性クラスターの自動化、スケーリング、管理に適したソリューションになりつつあります。 人気が高まっている結果、Kubernetesのセキュリティはますます重要になっています。
Kubernetesに関連する可動部分とさまざまなデプロイシナリオを考慮すると、Kubernetesのセキュリティ保護は複雑になる場合があります。 このため、この記事の目的は、 DigitalOcean Kubernetes(DOKS)クラスターの強固なセキュリティ基盤を提供することです。 このチュートリアルでは、Kubernetesの基本的なセキュリティ対策について説明しており、網羅的なガイドではなく、出発点となることを目的としています。 その他の手順については、Kubernetesの公式ドキュメントをご覧ください。
このガイドでは、DigitalOceanKubernetesクラスターを保護するための基本的な手順を実行します。 TLS / SSL証明書を使用して安全なローカル認証を構成し、ロールベースのアクセス制御(RBAC)を使用してローカルユーザーにアクセス許可を付与し、を使用してKubernetesアプリケーションとデプロイにアクセス許可を付与しますサービスアカウント、およびでリソース制限を設定します ResourceQuota
と LimitRange
アドミッションコントローラー。
前提条件
このチュートリアルを完了するには、次のものが必要です。
- 3つの標準ノードがそれぞれ少なくとも2GBRAMおよび1vCPUで構成されたDigitalOceanKubernetes(DOKS)マネージドクラスター。 DOKSクラスターを作成する方法の詳細については、Kubernetesクイックスタートガイドをご覧ください。 このチュートリアルでは、DOKSバージョン1.16.2-do.1を使用します。
- DigitalOceanコントロールパネルからダウンロードされ、次のように保存されたクラスター構成ファイルを使用してDOKSクラスターを管理するように構成されたローカルクライアント
~/.kube/config
. リモートDOKS管理を構成する方法の詳細については、ガイド DigitalOceanKubernetesClusterに接続する方法をお読みください。 特に、次のものが必要になります。- The
kubectl
ローカルマシンにインストールされているコマンドラインインターフェイス。 インストールと構成の詳細を読むことができますkubectl
公式ドキュメント。 このチュートリアルでは、kubectl
バージョン1.17.0-00。 - 公式のDigitalOceanコマンドラインツール、
doctl
. これをインストールする方法については、doctlGitHubページを参照してください。 このチュートリアルでは、doctl
バージョン1.36.0。
- The
ステップ1—リモートユーザー認証を有効にする
前提条件を完了すると、事前定義されたDigitalOceanベアラートークンを介して認証する1人のKubernetesスーパーユーザーができあがります。 ただし、これらの資格情報を共有することは、このアカウントがクラスターに大規模で破壊的な変更を引き起こす可能性があるため、適切なセキュリティ慣行ではありません。 この可能性を軽減するために、それぞれのローカルクライアントから認証される追加のユーザーを設定できます。
このセクションでは、安全なSSL / TLS証明書を使用して、ローカルクライアントからリモートDOKSクラスターに対して新しいユーザーを認証します。 これは3つのステップのプロセスになります。最初に、ユーザーごとに証明書署名要求(CSR)を作成し、次にそれらの証明書をクラスター内で直接承認します。 kubectl
. 最後に、適切な証明書を使用して各ユーザーにkubeconfigファイルを作成します。 Kubernetesでサポートされている追加の認証方法の詳細については、Kubernetes認証ドキュメントを参照してください。
新規ユーザー向けの証明書署名要求の作成
開始する前に、前提条件の間に構成されたローカルマシンからのDOKSクラスター接続を確認してください。
- kubectl cluster-info
構成に応じて、出力は次のようになります。
OutputKubernetes master is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com
CoreDNS is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
これは、DOKSクラスターに接続していることを意味します。
次に、クライアントの証明書用のローカルフォルダを作成します。 このガイドの目的のために、 ~/certs
すべての証明書を保存するために使用されます:
- mkdir ~/certs
このチュートリアルでは、sammyという新しいユーザーにクラスターへのアクセスを許可します。 これを選択したユーザーに自由に変更してください。 SSLおよびTLSライブラリOpenSSLを使用して、次のコマンドを使用してユーザーの新しい秘密鍵を生成します。
- openssl genrsa -out ~/certs/sammy.key 4096
The -out
フラグは出力ファイルを作成します ~/certs/sammy.key
、 と 4096
キーを4096ビットに設定します。 OpenSSLの詳細については、 OpenSSLEssentialsガイドを参照してください。
次に、証明書署名要求構成ファイルを作成します。 次のファイルをテキストエディタで開きます(このチュートリアルでは、 nano
):
- nano ~/certs/sammy.csr.cnf
次のコンテンツをに追加します sammy.csr.cnf
サブジェクトに共通名(CN)として目的のユーザー名を指定し、組織(O)としてグループを指定するファイル:
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
[ dn ]
CN = sammy
O = developers
[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
証明書署名要求の構成ファイルには、必要なすべての情報、ユーザーID、およびユーザーの適切な使用パラメーターが含まれています。 最後の議論 extendedKeyUsage=serverAuth,clientAuth
署名が完了すると、ユーザーは証明書を使用してDOKSクラスターでローカルクライアントを認証できるようになります。
次に、sammy証明書署名要求を作成します。
- openssl req -config ~/certs/sammy.csr.cnf -new -key ~/certs/sammy.key -nodes -out ~/certs/sammy.csr
The -config
CSRの構成ファイルを指定できます。 -new
によって指定されたキーの新しいCSRを作成していることを通知します -key
.
次のコマンドを実行して、証明書署名要求を確認できます。
- openssl req -in ~/certs/sammy.csr -noout -text
ここでは、CSRを -in
と使用 -text
証明書要求をテキストで印刷します。
出力には証明書リクエストが表示され、その先頭は次のようになります。
OutputCertificate Request:
Data:
Version: 1 (0x0)
Subject: CN = sammy, O = developers
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
...
同じ手順を繰り返して、追加のユーザーのCSRを作成します。 すべての証明書署名要求を管理者に保存したら ~/certs
フォルダで、次の手順に進んで承認します。
KubernetesAPIを使用した証明書署名要求の管理
Kubernetes APIに発行されたTLS証明書は、次を使用して承認または拒否できます。 kubectl
コマンドラインツール。 これにより、要求されたアクセスが特定のユーザーに適切であることを確認できます。 このセクションでは、 sammy の証明書リクエストを送信し、それを証明します。
CSRをDOKSクラスターに送信するには、次のコマンドを使用します。
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
name: sammy-authentication
spec:
groups:
- system:authenticated
request: $(cat ~/certs/sammy.csr | base64 | tr -d '\n')
usages:
- digital signature
- key encipherment
- server auth
- client auth
EOF
ヒアドキュメントを使用して、このコマンドは cat
証明書要求をに渡す kubectl apply
.
証明書のリクエストを詳しく見てみましょう。
name: sammy-authentication
メタデータ識別子を作成します。この場合はsammy-authentication
.request: $(cat ~/certs/sammy.csr | base64 | tr -d '\n')
を送信しますsammy.csr
Base64としてエンコードされたクラスターへの証明書署名要求。server auth
とclient auth
証明書の使用目的を指定します。 この場合、目的はユーザー認証です。
出力は次のようになります。
Outputcertificatesigningrequest.certificates.k8s.io/sammy-authentication created
次のコマンドを使用して、証明書署名要求のステータスを確認できます。
- kubectl get csr
クラスタ構成に応じて、出力は次のようになります。
OutputNAME AGE REQUESTOR CONDITION
sammy-authentication 37s your_DO_email Pending
次に、次のコマンドを使用してCSRを承認します。
- kubectl certificate approve sammy-authentication
操作を確認するメッセージが表示されます。
Outputcertificatesigningrequest.certificates.k8s.io/sammy-authentication approved
注:管理者は、コマンドを使用してCSRを拒否することもできます kubectl certificate deny sammy-authentication
. TLS証明書の管理の詳細については、Kubernetesの公式ドキュメントをご覧ください。
CSRが承認されたので、次のコマンドを実行して、CSRをローカルマシンにダウンロードできます。
- kubectl get csr sammy-authentication -o jsonpath='{.status.certificate}' | base64 --decode > ~/certs/sammy.crt
このコマンドは、Base64証明書をデコードして適切に使用できるようにします。 kubectl
、次に名前を付けて保存します ~/certs/sammy.crt
.
sammy 署名付き証明書が手元にあるので、ユーザーのkubeconfigファイルを作成できるようになりました。
リモートユーザーの構築Kubeconfig
次に、sammyユーザー用の特定のkubeconfigファイルを作成します。 これにより、ユーザーのクラスターへのアクセスをより細かく制御できるようになります。
新しいkubeconfigを構築する最初のステップは、現在のkubeconfigファイルのコピーを作成することです。 このガイドでは、新しいkubeconfigファイルが呼び出されます。 config-sammy
:
- cp ~/.kube/config ~/.kube/config-sammy
次に、新しいファイルを編集します。
- nano ~/.kube/config-sammy
このファイルの最初の8行は、クラスターとのSSL / TLS接続に必要な情報が含まれているため、保持してください。 次に、 user
パラメータを指定し、テキストを次の強調表示された行に置き換えて、ファイルが次のようになるようにします。
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: certificate_data
name: do-nyc1-do-cluster
contexts:
- context:
cluster: do-nyc1-do-cluster
user: sammy
name: do-nyc1-do-cluster
current-context: do-nyc1-do-cluster
kind: Config
preferences: {}
users:
- name: sammy
user:
client-certificate: /home/your_local_user/certs/sammy.crt
client-key: /home/your_local_user/certs/sammy.key
注:両方の場合 client-certificate
と client-key
、対応する証明書の場所への絶対パスを使用します。 さもないと、 kubectl
エラーが発生します。
ファイルを保存して終了します。
を使用して新しいユーザー接続をテストできます kubectl cluster-info
:
- kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy cluster-info
次のようなエラーが表示されます。
OutputTo further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Error from server (Forbidden): services is forbidden: User "sammy" cannot list resource "services" in API group "" in the namespace "kube-system"
ユーザーsammyには、クラスター上のリソースを一覧表示する権限がまだないため、このエラーが発生する可能性があります。 ユーザーへの承認の付与については、次のステップで説明します。 今のところ、出力はSSL / TLS接続が成功し、sammy認証クレデンシャルがKubernetesAPIによって受け入れられたことを確認しています。
ステップ2—ロールベースのアクセス制御(RBAC)によるユーザーの承認
ユーザーが認証されると、APIはKubernetesの組み込みのロールベースアクセス制御(RBAC)モデルを使用してその権限を決定します。 RBACは、割り当てられた役割に基づいてユーザー権限を制限する効果的な方法です。 セキュリティの観点から、RBACでは、ユーザーが機密データにアクセスしたり、スーパーユーザーレベルのコマンドを実行したりすることを制限するためのきめ細かい権限を設定できます。 ユーザーロールの詳細については、KubernetesRBACのドキュメントを参照してください。
このステップでは、 kubectl
事前定義されたロールeditをdefault名前空間のユーザーsammyに割り当てます。 本番環境では、カスタムロールやカスタムロールバインディングを使用することをお勧めします。
権限の付与
Kubernetesでは、権限を付与するということは、目的のロールをユーザーに割り当てることを意味します。 割当 edit
ユーザーsammyへのアクセス許可 default
次のコマンドを使用した名前空間:
- kubectl create rolebinding sammy-edit-role --clusterrole=edit --user=sammy --namespace=default
これにより、次のような出力が得られます。
Outputrolebinding.rbac.authorization.k8s.io/sammy-edit-role created
このコマンドをさらに詳しく分析してみましょう。
create rolebinding sammy-edit-role
この場合は呼ばれる新しいロールバインディングを作成しますsammy-edit-role
.--clusterrole=edit
事前定義された役割を割り当てますedit
グローバルスコープ(クラスターロール)で。--user=sammy
ロールをバインドするユーザーを指定します。--namespace=default
この場合、指定された名前空間内のユーザーロール権限を付与しますdefault
.
次に、ポッドをリストしてユーザー権限を確認します default
名前空間。 エラーが表示されない場合は、RBAC認証が期待どおりに機能しているかどうかを確認できます。
- kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy auth can-i get pods
次の出力が得られます。
Outputyes
sammy にアクセス許可を割り当てたので、次のセクションでそれらのアクセス許可を取り消す練習をすることができます。
権限の取り消し
Kubernetesでの権限の取り消しは、ユーザーロールバインディングを削除することで行われます。
このチュートリアルでは、 edit
次のコマンドを実行して、ユーザーsammyからロールを実行します。
- kubectl delete rolebinding sammy-edit-role
次の出力が得られます。
Outputrolebinding.rbac.authorization.k8s.io "sammy-edit-role" deleted
ユーザー権限が期待どおりに取り消されたかどうかを確認するには、 default
名前空間ポッド:
- kubectl --kubeconfig=/home/localuser/.kube/config-sammy --namespace=default get pods
次のエラーが表示されます。
OutputError from server (Forbidden): pods is forbidden: User "sammy" cannot list resource "pods" in API group "" in the namespace "default"
これは、承認が取り消されたことを示しています。
セキュリティの観点から、Kubernetes認証モデルにより、クラスタ管理者は必要に応じてオンデマンドでユーザー権限を変更できる柔軟性が得られます。 さらに、役割ベースのアクセス制御は物理ユーザーに限定されません。 次のセクションで学習するように、クラスターサービスへのアクセス許可を付与および削除することもできます。
RBAC承認とカスタムロールの作成方法の詳細については、公式ドキュメントをお読みください。
ステップ3—サービスアカウントを使用したアプリケーションのアクセス許可の管理
前のセクションで述べたように、RBAC認証メカニズムは人間のユーザーを超えて拡張されます。 ポッド内で実行されているアプリケーション、サービス、プロセスなどの人間以外のクラスターユーザーは、Kubernetesがサービスアカウントと呼ぶものを使用してAPIサーバーで認証します。 名前空間内にポッドを作成する場合は、ポッドに使用させることができます。 default
サービスアカウントまたは任意のサービスアカウントを定義できます。 個々のSAをアプリケーションとプロセスに割り当てる機能により、管理者は必要に応じてアクセス許可を付与または取り消すことができます。 さらに、特定のSAを本番環境に不可欠なアプリケーションに割り当てることは、セキュリティのベストプラクティスと見なされます。 サービスアカウントは認証、つまりRBAC承認チェックに使用されるため、クラスター管理者は、サービスアカウントのアクセス権を変更し、問題のあるプロセスを分離することで、セキュリティの脅威を封じ込めることができます。
サービスアカウントを示すために、このチュートリアルでは、サンプルアプリケーションとして NginxWebサーバーを使用します。
アプリケーションに特定のSAを割り当てる前に、SAを作成する必要があります。 と呼ばれる新しいサービスアカウントを作成します nginx-sa
の中に default
名前空間:
- kubectl create sa nginx-sa
あなたが得るでしょう:
Outputserviceaccount/nginx-sa created
次のコマンドを実行して、サービスアカウントが作成されたことを確認します。
- kubectl get sa
これにより、サービスアカウントのリストが表示されます。
OutputNAME SECRETS AGE
default 1 22h
nginx-sa 1 80s
次に、に役割を割り当てます nginx-sa
サービスアカウント。 この例では、 nginx-sa
sammy ユーザーと同じ権限:
- kubectl create rolebinding nginx-sa-edit \
- --clusterrole=edit \
- --serviceaccount=default:nginx-sa \
- --namespace=default
これを実行すると、次のようになります。
Outputrolebinding.rbac.authorization.k8s.io/nginx-sa-edit created
このコマンドは、ユーザー sammy と同じ形式を使用しますが、 --serviceaccount=default:nginx-sa
フラグ、ここで割り当てます nginx-sa
のサービスアカウント default
名前空間。
次のコマンドを使用して、役割のバインドが成功したことを確認します。
- kubectl get rolebinding
これにより、次の出力が得られます。
OutputNAME AGE
nginx-sa-edit 23s
サービスアカウントのロールバインディングが正常に構成されたことを確認したら、サービスアカウントをアプリケーションに割り当てることができます。 特定のサービスアカウントをアプリケーションに割り当てると、そのアクセス権をリアルタイムで管理できるため、クラスターのセキュリティが強化されます。
このチュートリアルの目的のために、 nginx
ポッドはサンプルアプリケーションとして機能します。 新しいポッドを作成し、 nginx-sa
次のコマンドを使用したサービスアカウント:
- kubectl run nginx --image=nginx --port 80 --serviceaccount="nginx-sa"
コマンドの最初の部分は、を実行する新しいポッドを作成します nginx
ポート上のWebサーバー :80
、および最後の部分 --serviceaccount="nginx-sa"
このポッドが使用する必要があることを示します nginx-sa
サービスアカウントではなく default
SA。
これにより、次のような出力が得られます。
Outputdeployment.apps/nginx created
を使用して、新しいアプリケーションがサービスアカウントを使用していることを確認します kubectl describe
:
- kubectl describe deployment nginx
これにより、デプロイメントパラメータの長い説明が出力されます。 下 Pod Template
セクションでは、次のような出力が表示されます。
Output...
Pod Template:
Labels: run=nginx
Service Account: nginx-sa
...
このセクションでは、 nginx-sa
のサービスアカウント default
名前空間とそれに割り当てられた nginx
Webサーバー。 今、あなたは制御することができます nginx
必要に応じて役割を変更することにより、リアルタイムで権限を付与します。 同じサービスアカウントを各アプリケーションに割り当ててアプリケーションをグループ化し、アクセス許可を一括変更することもできます。 最後に、重要なアプリケーションに一意のSAを割り当てることで、それらを分離できます。
要約すると、アプリケーション/デプロイメントに役割を割り当てる背後にある考え方は、アクセス許可を微調整することです。 実際の実稼働環境では、読み取り専用から完全な管理者権限まで、さまざまな権限を必要とする複数のデプロイメントがある場合があります。 RBACを使用すると、必要に応じてクラスターへのアクセスを制限する柔軟性が得られます。
次に、リソースを制御し、リソース不足攻撃から保護するためのアドミッションコントローラーを設定します。
ステップ4—アドミッションコントローラーの設定
Kubernetes アドミッションコントローラーは、にコンパイルされるオプションのプラグインです。 kube-apiserver
セキュリティオプションを広げるためのバイナリ。 アドミッションコントローラは、認証および承認フェーズを通過した後、リクエストをインターセプトします。 リクエストがインターセプトされると、アドミッションコントローラはリクエストが適用される直前に指定されたコードを実行します。
認証または承認チェックの結果は、要求を許可または拒否するブール値ですが、アドミッションコントローラーははるかに多様になる可能性があります。 アドミッションコントローラは、認証と同じ方法でリクエストを検証できますが、リクエストを変更したり、リクエストを変更したり、オブジェクトを変更してから許可することもできます。
このステップでは、 ResourceQuota
と LimitRange
リソース不足またはサービス拒否攻撃の原因となる可能性のある要求を変更することにより、クラスターを保護するためのアドミッションコントローラー。 The ResourceQuota
アドミッションコントローラを使用すると、管理者は、コンピューティングリソース、ストレージリソース、および名前空間内のオブジェクトの量を制限できます。 LimitRange
アドミッションコントローラーは、コンテナーが使用するリソースの数を制限します。 これらの2つのアドミッションコントローラーを一緒に使用すると、リソースを使用できなくする攻撃からクラスターを保護できます。
方法を示すために ResourceQuota
動作します、あなたはいくつかの制限を実装します default
名前空間。 新しいものを作成することから始めます ResourceQuota
オブジェクトファイル:
- nano resource-quota-default.yaml
次のオブジェクト定義を追加して、リソース消費の制約を設定します。 default
名前空間。 ノードの物理リソースに応じて、必要に応じて値を調整できます。
apiVersion: v1
kind: ResourceQuota
metadata:
name: resource-quota-default
spec:
hard:
pods: "2"
requests.cpu: "500m"
requests.memory: 1Gi
limits.cpu: "1000m"
limits.memory: 2Gi
configmaps: "5"
persistentvolumeclaims: "2"
replicationcontrollers: "10"
secrets: "3"
services: "4"
services.loadbalancers: "2"
この定義では、 hard
の最大数などのハード制約を設定するキーワード pods
, configmaps
, PersistentVolumeClaims
, ReplicationControllers
, secrets
, services
、 と loadbalancers
. これにより、次のようなコンピューティングリソースにも制約が生じます。
requests.cpu
、 milliCPU のリクエストの最大CPU値、つまりCPUコアの1000分の1を設定します。requests.memory
、リクエストの最大メモリ値をバイト単位で設定します。limits.cpu
、ミリCPU単位の制限の最大CPU値を設定します。limits.memory
、制限の最大メモリ値をバイト単位で設定します。
ファイルを保存して終了します。
次に、次のコマンドを実行して、名前空間にオブジェクトを作成します。
- kubectl create -f resource-quota-default.yaml --namespace=default
これにより、次のようになります。
Outputresourcequota/resource-quota-default created
を使用していることに注意してください -f
Kubernetesに場所を示すフラグ ResourceQuota
ファイルと --namespace
更新する名前空間を指定するフラグ。
オブジェクトが作成されると、 ResourceQuota
アクティブになります。 あなたはチェックすることができます default
名前空間のクォータ describe quota
:
- kubectl describe quota --namespace=default
出力はこれに似ていますが、で設定したハード制限があります resource-quota-default.yaml
ファイル:
OutputName: resource-quota-default
Namespace: default
Resource Used Hard
-------- ---- ----
configmaps 0 5
limits.cpu 0 1
limits.memory 0 2Gi
persistentvolumeclaims 0 2
pods 1 2
replicationcontrollers 0 10
requests.cpu 0 500m
requests.memory 0 1Gi
secrets 2 3
services 1 4
services.loadbalancers 0 2
ResourceQuotas
は絶対単位で表されるため、ノードを追加しても、ここで定義された値は自動的に増加しません。 さらにノードを追加する場合は、ここで値を手動で編集して、リソースを比例配分する必要があります。 ResourceQuotas
必要に応じて何度でも変更できますが、名前空間全体を削除しない限り、削除することはできません。
特定のを変更する必要がある場合 ResourceQuota
、対応する更新 .yaml
次のコマンドを使用して、ファイルを作成し、変更を適用します。
- kubectl apply -f resource-quota-default.yaml --namespace=default
に関する詳細については ResourceQuota
アドミッションコントローラーについては、公式ドキュメントを参照してください。
今あなたの ResourceQuota
が設定されたら、設定に進みます LimitRange
アドミッションコントローラー。 どのように ResourceQuota
名前空間に制限を適用します。 LimitRange
コンテナの検証と変更によって宣言された制限を適用します。
以前と同様に、オブジェクトファイルを作成することから始めます。
- nano limit-range-default.yaml
今、あなたは使用することができます LimitRange
必要に応じてリソースの使用を制限するオブジェクト。 典型的なユースケースの例として、次のコンテンツを追加します。
apiVersion: v1
kind: LimitRange
metadata:
name: limit-range-default
spec:
limits:
- max:
cpu: "400m"
memory: "1Gi"
min:
cpu: "100m"
memory: "100Mi"
default:
cpu: "250m"
memory: "800Mi"
defaultRequest:
cpu: "150m"
memory: "256Mi"
type: Container
で使用されるサンプル値 limit-ranges-default.yaml
コンテナメモリを最大1Giに制限し、CPU使用量を最大 400m に制限します。これは、400ミリCPUに相当するKubernetesメトリックです。コアのほぼ半分を使用するように制限されています。
次に、次のコマンドを使用して、オブジェクトをAPIサーバーにデプロイします。
- kubectl create -f limit-range-default.yaml --namespace=default
これにより、次の出力が得られます。
Outputlimitrange/limit-range-default created
これで、次のコマンドで新しい制限を確認できます。
- kubectl describe limits --namespace=default
出力は次のようになります。
OutputName: limit-range-default
Namespace: default
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Container cpu 100m 400m 150m 250m -
Container memory 100Mi 1Gi 256Mi 800Mi -
見る LimitRanger
実際には、標準をデプロイします nginx
次のコマンドを使用したコンテナ:
- kubectl run nginx --image=nginx --port=80 --restart=Never
これにより、次の出力が得られます。
Outputpod/nginx created
次のコマンドを実行して、アドミッションコントローラーがコンテナーをどのように変更したかを確認します。
- kubectl get pod nginx -o yaml
これにより、多くの出力行が得られます。 コンテナ仕様セクションを調べて、で指定されているリソース制限を見つけます。 LimitRange
アドミッションコントローラー:
Output...
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: nginx
ports:
- containerPort: 80
protocol: TCP
resources:
limits:
cpu: 250m
memory: 800Mi
requests:
cpu: 150m
memory: 256Mi
...
これは、手動で宣言した場合と同じです。 resources
と requests
コンテナ仕様で。
このステップでは、 ResourceQuota
と LimitRange
クラスタのリソースに対する悪意のある攻撃から保護するためのアドミッションコントローラ。 詳細については LimitRange
入場管理者は、公式文書をお読みください。
結論
このガイド全体を通して、基本的なKubernetesセキュリティテンプレートを設定しました。 この確立されたユーザー認証と承認、アプリケーション特権、およびクラスターリソース保護。 この記事で取り上げたすべての提案を組み合わせると、Kubernetesクラスターを本番環境にデプロイするための強固な基盤が得られます。 そこから、シナリオに応じて、クラスターの個々の側面を強化し始めることができます。
Kubernetesの詳細については、 Kubernetesリソースページを確認するか、フルスタック開発者向けKubernetesセルフガイドコースをご覧ください。