序章

オープンソースのコンテナオーケストレーションプラットフォームであるKubernetesは、高可用性クラスターの自動化、スケーリング、管理に適したソリューションになりつつあります。 人気が高まっている結果、Kubernetesのセキュリティはますます重要になっています。

Kubernetesに関連する可動部分とさまざまなデプロイシナリオを考慮すると、Kubernetesのセキュリティ保護は複雑になる場合があります。 このため、この記事の目的は、 DigitalOcean Kubernetes(DOKS)クラスターの強固なセキュリティ基盤を提供することです。 このチュートリアルでは、Kubernetesの基本的なセキュリティ対策について説明しており、網羅的なガイドではなく、出発点となることを目的としています。 その他の手順については、Kubernetesの公式ドキュメントをご覧ください。

このガイドでは、DigitalOceanKubernetesクラスターを保護するための基本的な手順を実行します。 TLS / SSL証明書を使用して安全なローカル認証を構成し、ロールベースのアクセス制御(RBAC)を使用してローカルユーザーにアクセス許可を付与し、を使用してKubernetesアプリケーションとデプロイにアクセス許可を付与しますサービスアカウント、およびでリソース制限を設定します ResourceQuotaLimitRange アドミッションコントローラー。

前提条件

このチュートリアルを完了するには、次のものが必要です。

  • 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。

ステップ1—リモートユーザー認証を有効にする

前提条件を完了すると、事前定義されたDigitalOceanベアラートークンを介して認証する1人のKubernetesスーパーユーザーができあがります。 ただし、これらの資格情報を共有することは、このアカウントがクラスターに大規模で破壊的な変更を引き起こす可能性があるため、適切なセキュリティ慣行ではありません。 この可能性を軽減するために、それぞれのローカルクライアントから認証される追加のユーザーを設定できます。

このセクションでは、安全なSSL / TLS証明書を使用して、ローカルクライアントからリモートDOKSクラスターに対して新しいユーザーを認証します。 これは3つのステップのプロセスになります。最初に、ユーザーごとに証明書署名要求(CSR)を作成し、次にそれらの証明書をクラスター内で直接承認します。 kubectl. 最後に、適切な証明書を使用して各ユーザーにkubeconfigファイルを作成します。 Kubernetesでサポートされている追加の認証方法の詳細については、Kubernetes認証ドキュメントを参照してください。

新規ユーザー向けの証明書署名要求の作成

開始する前に、前提条件の間に構成されたローカルマシンからのDOKSクラスター接続を確認してください。

  1. kubectl cluster-info

構成に応じて、出力は次のようになります。

Output
Kubernetes 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 すべての証明書を保存するために使用されます:

  1. mkdir ~/certs

このチュートリアルでは、sammyという新しいユーザーにクラスターへのアクセスを許可します。 これを選択したユーザーに自由に変更してください。 SSLおよびTLSライブラリOpenSSLを使用して、次のコマンドを使用してユーザーの新しい秘密鍵を生成します。

  1. openssl genrsa -out ~/certs/sammy.key 4096

The -out フラグは出力ファイルを作成します ~/certs/sammy.key、 と 4096 キーを4096ビットに設定します。 OpenSSLの詳細については、 OpenSSLEssentialsガイドを参照してください。

次に、証明書署名要求構成ファイルを作成します。 次のファイルをテキストエディタで開きます(このチュートリアルでは、 nano):

  1. nano ~/certs/sammy.csr.cnf

次のコンテンツをに追加します sammy.csr.cnf サブジェクトに共通名(CN)として目的のユーザー名を指定し、組織(O)としてグループを指定するファイル:

〜/ certs / sammy.csr.cnf
[ 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証明書署名要求を作成します。

  1. openssl req -config ~/certs/sammy.csr.cnf -new -key ~/certs/sammy.key -nodes -out ~/certs/sammy.csr

The -config CSRの構成ファイルを指定できます。 -new によって指定されたキーの新しいCSRを作成していることを通知します -key.

次のコマンドを実行して、証明書署名要求を確認できます。

  1. openssl req -in ~/certs/sammy.csr -noout -text

ここでは、CSRを -in と使用 -text 証明書要求をテキストで印刷します。

出力には証明書リクエストが表示され、その先頭は次のようになります。

Output
Certificate 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 authclient auth 証明書の使用目的を指定します。 この場合、目的はユーザー認証です。

出力は次のようになります。

Output
certificatesigningrequest.certificates.k8s.io/sammy-authentication created

次のコマンドを使用して、証明書署名要求のステータスを確認できます。

  1. kubectl get csr

クラスタ構成に応じて、出力は次のようになります。

Output
NAME AGE REQUESTOR CONDITION sammy-authentication 37s your_DO_email Pending

次に、次のコマンドを使用してCSRを承認します。

  1. kubectl certificate approve sammy-authentication

操作を確認するメッセージが表示されます。

Output
certificatesigningrequest.certificates.k8s.io/sammy-authentication approved

注:管理者は、コマンドを使用してCSRを拒否することもできます kubectl certificate deny sammy-authentication. TLS証明書の管理の詳細については、Kubernetesの公式ドキュメントをご覧ください。

CSRが承認されたので、次のコマンドを実行して、CSRをローカルマシンにダウンロードできます。

  1. 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:

  1. cp ~/.kube/config ~/.kube/config-sammy

次に、新しいファイルを編集します。

  1. nano ~/.kube/config-sammy

このファイルの最初の8行は、クラスターとのSSL / TLS接続に必要な情報が含まれているため、保持してください。 次に、 user パラメータを指定し、テキストを次の強調表示された行に置き換えて、ファイルが次のようになるようにします。

config-sammy
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-certificateclient-key、対応する証明書の場所への絶対パスを使用します。 さもないと、 kubectl エラーが発生します。

ファイルを保存して終了します。

を使用して新しいユーザー接続をテストできます kubectl cluster-info:

  1. kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy cluster-info

次のようなエラーが表示されます。

Output
To 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 事前定義されたロールeditdefault名前空間のユーザーsammyに割り当てます。 本番環境では、カスタムロールやカスタムロールバインディングを使用することをお勧めします。

権限の付与

Kubernetesでは、権限を付与するということは、目的のロールをユーザーに割り当てることを意味します。 割当 edit ユーザーsammyへのアクセス許可 default 次のコマンドを使用した名前空間:

  1. kubectl create rolebinding sammy-edit-role --clusterrole=edit --user=sammy --namespace=default

これにより、次のような出力が得られます。

Output
rolebinding.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認証が期待どおりに機能しているかどうかを確認できます。

  1. kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy auth can-i get pods

次の出力が得られます。

Output
yes

sammy にアクセス許可を割り当てたので、次のセクションでそれらのアクセス許可を取り消す練習をすることができます。

権限の取り消し

Kubernetesでの権限の取り消しは、ユーザーロールバインディングを削除することで行われます。

このチュートリアルでは、 edit 次のコマンドを実行して、ユーザーsammyからロールを実行します。

  1. kubectl delete rolebinding sammy-edit-role

次の出力が得られます。

Output
rolebinding.rbac.authorization.k8s.io "sammy-edit-role" deleted

ユーザー権限が期待どおりに取り消されたかどうかを確認するには、 default 名前空間ポッド:

  1. kubectl --kubeconfig=/home/localuser/.kube/config-sammy --namespace=default get pods

次のエラーが表示されます。

Output
Error 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 名前空間:

  1. kubectl create sa nginx-sa

あなたが得るでしょう:

Output
serviceaccount/nginx-sa created

次のコマンドを実行して、サービスアカウントが作成されたことを確認します。

  1. kubectl get sa

これにより、サービスアカウントのリストが表示されます。

Output
NAME SECRETS AGE default 1 22h nginx-sa 1 80s

次に、に役割を割り当てます nginx-sa サービスアカウント。 この例では、 nginx-sa sammy ユーザーと同じ権限:

  1. kubectl create rolebinding nginx-sa-edit \
  2. --clusterrole=edit \
  3. --serviceaccount=default:nginx-sa \
  4. --namespace=default

これを実行すると、次のようになります。

Output
rolebinding.rbac.authorization.k8s.io/nginx-sa-edit created

このコマンドは、ユーザー sammy と同じ形式を使用しますが、 --serviceaccount=default:nginx-sa フラグ、ここで割り当てます nginx-sa のサービスアカウント default 名前空間。

次のコマンドを使用して、役割のバインドが成功したことを確認します。

  1. kubectl get rolebinding

これにより、次の出力が得られます。

Output
NAME AGE nginx-sa-edit 23s

サービスアカウントのロールバインディングが正常に構成されたことを確認したら、サービスアカウントをアプリケーションに割り当てることができます。 特定のサービスアカウントをアプリケーションに割り当てると、そのアクセス権をリアルタイムで管理できるため、クラスターのセキュリティが強化されます。

このチュートリアルの目的のために、 nginx ポッドはサンプルアプリケーションとして機能します。 新しいポッドを作成し、 nginx-sa 次のコマンドを使用したサービスアカウント:

  1. kubectl run nginx --image=nginx --port 80 --serviceaccount="nginx-sa"

コマンドの最初の部分は、を実行する新しいポッドを作成します nginx ポート上のWebサーバー :80、および最後の部分 --serviceaccount="nginx-sa" このポッドが使用する必要があることを示します nginx-sa サービスアカウントではなく default SA。

これにより、次のような出力が得られます。

Output
deployment.apps/nginx created

を使用して、新しいアプリケーションがサービスアカウントを使用していることを確認します kubectl describe:

  1. 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 セキュリティオプションを広げるためのバイナリ。 アドミッションコントローラは、認証および承認フェーズを通過した後、リクエストをインターセプトします。 リクエストがインターセプトされると、アドミッションコントローラはリクエストが適用される直前に指定されたコードを実行します。

認証または承認チェックの結果は、要求を許可または拒否するブール値ですが、アドミッションコントローラーははるかに多様になる可能性があります。 アドミッションコントローラは、認証と同じ方法でリクエストを検証できますが、リクエストを変更したり、リクエストを変更したり、オブジェクトを変更してから許可することもできます。

このステップでは、 ResourceQuotaLimitRange リソース不足またはサービス拒否攻撃の原因となる可能性のある要求を変更することにより、クラスターを保護するためのアドミッションコントローラー。 The ResourceQuota アドミッションコントローラを使用すると、管理者は、コンピューティングリソース、ストレージリソース、および名前空間内のオブジェクトの量を制限できます。 LimitRange アドミッションコントローラーは、コンテナーが使用するリソースの数を制限します。 これらの2つのアドミッションコントローラーを一緒に使用すると、リソースを使用できなくする攻撃からクラスターを保護できます。

方法を示すために ResourceQuota 動作します、あなたはいくつかの制限を実装します default 名前空間。 新しいものを作成することから始めます ResourceQuota オブジェクトファイル:

  1. nano resource-quota-default.yaml

次のオブジェクト定義を追加して、リソース消費の制約を設定します。 default 名前空間。 ノードの物理リソースに応じて、必要に応じて値を調整できます。

resource-quota-default.yaml
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、制限の最大メモリ値をバイト単位で設定します。

ファイルを保存して終了します。

次に、次のコマンドを実行して、名前空間にオブジェクトを作成します。

  1. kubectl create -f resource-quota-default.yaml --namespace=default

これにより、次のようになります。

Output
resourcequota/resource-quota-default created

を使用していることに注意してください -f Kubernetesに場所を示すフラグ ResourceQuota ファイルと --namespace 更新する名前空間を指定するフラグ。

オブジェクトが作成されると、 ResourceQuota アクティブになります。 あなたはチェックすることができます default 名前空間のクォータ describe quota:

  1. kubectl describe quota --namespace=default

出力はこれに似ていますが、で設定したハード制限があります resource-quota-default.yaml ファイル:

Output
Name: 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 次のコマンドを使用して、ファイルを作成し、変更を適用します。

  1. kubectl apply -f resource-quota-default.yaml --namespace=default

に関する詳細については ResourceQuota アドミッションコントローラーについては、公式ドキュメントを参照してください。

今あなたの ResourceQuota が設定されたら、設定に進みます LimitRange アドミッションコントローラー。 どのように ResourceQuota 名前空間に制限を適用します。 LimitRange コンテナの検証と変更によって宣言された制限を適用します。

以前と同様に、オブジェクトファイルを作成することから始めます。

  1. nano limit-range-default.yaml

今、あなたは使用することができます LimitRange 必要に応じてリソースの使用を制限するオブジェクト。 典型的なユースケースの例として、次のコンテンツを追加します。

limit-ranges-default.yaml
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サーバーにデプロイします。

  1. kubectl create -f limit-range-default.yaml --namespace=default

これにより、次の出力が得られます。

Output
limitrange/limit-range-default created

これで、次のコマンドで新しい制限を確認できます。

  1. kubectl describe limits --namespace=default

出力は次のようになります。

Output
Name: 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 次のコマンドを使用したコンテナ:

  1. kubectl run nginx --image=nginx --port=80 --restart=Never

これにより、次の出力が得られます。

Output
pod/nginx created

次のコマンドを実行して、アドミッションコントローラーがコンテナーをどのように変更したかを確認します。

  1. 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 ...

これは、手動で宣言した場合と同じです。 resourcesrequests コンテナ仕様で。

このステップでは、 ResourceQuotaLimitRange クラスタのリソースに対する悪意のある攻撃から保護するためのアドミッションコントローラ。 詳細については LimitRange 入場管理者は、公式文書をお読みください。

結論

このガイド全体を通して、基本的なKubernetesセキュリティテンプレートを設定しました。 この確立されたユーザー認証と承認、アプリケーション特権、およびクラスターリソース保護。 この記事で取り上げたすべての提案を組み合わせると、Kubernetesクラスターを本番環境にデプロイするための強固な基盤が得られます。 そこから、シナリオに応じて、クラスターの個々の側面を強化し始めることができます。

Kubernetesの詳細については、 Kubernetesリソースページを確認するか、フルスタック開発者向けKubernetesセルフガイドコースをご覧ください。