DigitalOceanKubernetesクラスターを保護するための推奨手順

提供：Dev Guides
移動先:案内、検索

著者は、 Write for DOnations プログラムの一環として、 Open Sourcing MentalIllnessを選択して寄付を受け取りました。

序章

オープンソースのコンテナオーケストレーションプラットフォームである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コントロールパネルからダウンロードされ~/.kube/configとして保存されたクラスター構成ファイルを使用して、DOKSクラスターを管理するように構成されたローカルクライアント。 リモートDOKS管理を構成する方法の詳細については、ガイド DigitalOceanKubernetesClusterに接続する方法をお読みください。 特に、次のものが必要になります。 ローカルマシンにインストールされている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クラスター接続を確認してください。 

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

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

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

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証明書署名要求を作成します。 

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

-configを使用すると、CSRの構成ファイルを指定でき、-newは、-keyで指定されたキーの新しいCSRを作成していることを通知します。

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

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

ここでは、-inを使用してCSRを渡し、-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を使用した証明書署名要求の管理

kubectlコマンドラインツールを使用して、KubernetesAPIに発行されたTLS証明書を承認または拒否できます。 これにより、要求されたアクセスが特定のユーザーに適切であることを確認できます。 このセクションでは、 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

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


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

kubectl get csr sammy-authentication -o jsonpath='{.status.certificate}' | base64 --decode > ~/certs/sammy.crt

このコマンドは、kubectlで適切に使用できるようにBase64証明書をデコードしてから、~/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パラメータから始めて、テキストを次の強調表示された行に置き換え、ファイルが次のようになるようにします。

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

権限の付与

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

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での権限の取り消しは、ユーザーロールバインディングを削除することで行われます。

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

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を作成する必要があります。 default名前空間にnginx-saという名前の新しいサービスアカウントを作成します。 

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

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

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

kubectl get rolebinding

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

OutputNAME            AGE
nginx-sa-edit   23s

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

このチュートリアルでは、nginxポッドがサンプルアプリケーションとして機能します。 新しいポッドを作成し、次のコマンドでnginx-saサービスアカウントを指定します。 

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

コマンドの最初の部分は、ポート:80でnginx Webサーバーを実行する新しいポッドを作成し、最後の部分--serviceaccount="nginx-sa"は、このポッドが[を使用する必要があることを示します。 X176X]サービスアカウントであり、defaultSAではありません。

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

Outputdeployment.apps/nginx created

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

kubectl describe deployment nginx

これにより、デプロイメントパラメータの長い説明が出力されます。 Pod Templateセクションの下に、次のような出力が表示されます。 

Output...
Pod Template:
 Labels: run=nginx
 Service Account: nginx-sa
...

このセクションでは、default名前空間にnginx-saサービスアカウントを作成し、それをnginxWebサーバーに割り当てました。 これで、必要に応じて役割を変更することにより、nginx権限をリアルタイムで制御できます。 同じサービスアカウントを各アプリケーションに割り当ててアプリケーションをグループ化し、アクセス許可を一括変更することもできます。 最後に、重要なアプリケーションに一意のSAを割り当てることで、それらを分離できます。

要約すると、アプリケーション/デプロイメントに役割を割り当てる背後にある考え方は、アクセス許可を微調整することです。 実際の実稼働環境では、読み取り専用から完全な管理者権限まで、さまざまな権限を必要とする複数のデプロイメントがある場合があります。 RBACを使用すると、必要に応じてクラスターへのアクセスを制限する柔軟性が得られます。

次に、リソースを制御し、リソース不足攻撃から保護するためのアドミッションコントローラーを設定します。

ステップ4—アドミッションコントローラーの設定

Kubernetes アドミッションコントローラーは、セキュリティオプションを拡張するためにkube-apiserverバイナリにコンパイルされるオプションのプラグインです。 アドミッションコントローラは、認証および承認フェーズを通過した後、リクエストをインターセプトします。 リクエストがインターセプトされると、アドミッションコントローラはリクエストが適用される直前に指定されたコードを実行します。

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

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

ResourceQuotaがどのように機能するかを示すために、default名前空間にいくつかの制限を実装します。 新しいResourceQuotaオブジェクトファイルを作成することから始めます。 

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。リクエストの最大CPU値をmilliCPU、つまり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フラグを使用してResourceQuotaファイルの場所をKubernetesに示し、--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オブジェクトを使用して、必要に応じてリソースの使用を制限できます。 典型的なユースケースの例として、次のコンテンツを追加します。

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 に制限します。これは、[X186Xと同等のKubernetesメトリックです] 400ミリCPU。これは、コンテナがコアのほぼ半分を使用するように制限されていることを意味します。

次に、次のコマンドを使用して、オブジェクトを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セルフガイドコースをご覧ください。

「https://www.finddevguides.com/index.php?title=DigitalOceanKubernetesクラスターを保護するための推奨手順&oldid=106939」から取得
Powered by MediaWiki