Kubernetes デプロイメントでセキュリティをブートストラップする方法

Kubernetes デプロイメントでセキュリティをブートストラップする方法

[[426719]]

[51CTO.com クイック翻訳] Kubernetes は、人気があり、一般的に使用されているコンテナ オーケストレーション ツールの 1 つです。 Kubernetes ワークロードは、単純な nginx サーバーや cron ジョブのように実行されるアプリケーションです。 Kubernetes デプロイメントは、簡単に更新、拡張、管理できるため、最も一般的に使用されるワークロードの 1 つになりました。

最近リリースされた Kubernetes Hardening Guide は、Kubernetes を効果的に保護する方法に関するガイダンスを提供する優れたリソースです。このガイドで提供される情報により、Kubernetes のセキュリティ保護と強化は Kubernetes 管理者の仕事であるだけでなく、クラスターにワークロードをデプロイする開発者の仕事でもあることが明確になります。

この記事では、Kubernetes ワークロードを展開する開発者が「Kubernetes 強化ガイド」で提供されているガイダンスの一部を適用して、セキュリティを強化する方法について説明します。

これは、シンプルな Dockerfile を基にセキュリティのベスト プラクティスを段階的に追加して、開発者がすぐに再利用できるテンプレート デプロイメント マニフェスト ファイルを作成する実用的なガイドです。

前提条件

  • ゼロから構築するため、Docker が必要です。
  • minikube のような単一ノードの Kubernetes クラスターでは、kubectl ユーティリティとともにこのガイドに従う必要があります。開発者は公式の minikube ドキュメントを使用して、自分の環境で設定することができます。

WSL2 にバンドルされた Docker Desktop によって作成されたスタンドアロン クラスターをバックエンドとして使用します。

このガイドでは、次のコードに示すように、kubectl ユーティリティを介してアクセスできる実行中のクラスターがあることを前提としています。

  1. シェル
  2. git クローン [email protected]:salecharohit/bootstrapsecurityinkubernetesdeployment.git
  3.  cd スプリングブートメイヴン
  4. docker ビルド 。 -f Dockerfile.basic -t springbootmaven
  5.  docker run --name springboot -d -p 8080:8080 springbootmaven  
  6. カール http://localhost:8080
  8. 予想される応答:
  10.  Alpine OSでMaven を使用して Spring Boot ビルドからHello World にアクセスしましょう!

安全な導入

Kubernetes ワークロードのセキュリティ保護は、実質的に「ビルド時」のセキュリティと「ランタイム」のセキュリティに分けることができます。これらの例を実行するには、このシンプルな Spring Boot Hello World アプリケーションを使用し、ビルド時のセキュリティとランタイム セキュリティの両方を適用して Kubernetes にデプロイします。関連するURLは次のとおりです：https://github.com/salecharohit/bootstrapsecurityinkubernetesdeployment

始める前に、このリポジトリをクローンし、Docker コンテナを構築して、アプリケーションをローカルで実行します。

ビルド時のセキュリティ

ビルド時のセキュリティでは、基盤となるコンテナがフットプリントを削減してビルドされ、可能な限り少ない権限で実行されるようにプログラムされる方法に重点を置いています。

以下では、問題の解決策を使用して、両方のアプローチについて説明します。

（１）攻撃対象領域を減らす

コンテナ内にアプリケーションを構築する場合の主な目標は、データセンター、クラウド プラットフォーム、オンプレミス施設など、実行される環境に関係なく、アプリケーションが常に独立して実行されるようにすることです。ただし、これらのアプリケーションを構築する際には、スタンドアロン アプリケーションであり、依存関係があまりないという暗黙のルールがあります。

SpringBoot アプリケーションを例に挙げます。このアプリケーションを実行するために必要な唯一の依存関係は、JVM または Java ランタイムです。コンテナ内の他のものは事実上役に立たなくなります。

たとえば、AlpineOS 上に構築された SpringBoot コンテナーでは、apk パッケージ マネージャーを特にインストールする必要はありません。

  1. シェル
  2. docker exec -it springboot /bin/sh
  3.  apk追加カール

したがって、apk バイナリを削除して Docker イメージを再構築してみてください。

この時点で、Dockerfile.asr を使用して Docker コンテナが再構築され、次のように共有されます。

  1.  Dockerファイル
  2. maven:3.8.1-openjdk-17-slimからMAVEN_BUILDとして
  3. ワークディレクトリ /build/
  4.  pom.xml /build/ をコピーします。
  5. コピー src /build/src/
  6.  mvnパッケージを実行する
  8. openjdk:17-alpineより
  10. 実行rm -f /sbin/apk && \
  11.  rm -rf /etc/apk && \
  12.  rm -rf /lib/apk && \
  13.  rm -rf /usr/share/apk && \
  14.  rm -rf rm -rf /var/lib/apk
  16. コピー--from=MAVEN_BUILD /build/target/springbootmaven.jar /springbootmaven.jar  
  17. エクスポーズ8080
  18. コマンド java -jar /springbootmaven.jar

ここで再構築して再実行します:

  1. シェル
  2. #まず、以前実行していたコンテナを停止しましょう
  3. docker の springboot を停止する
  4. #次に再構築して再実行してみましょう
  5. docker ビルド 。 -f Dockerfile.asr -t springbootmaven
  6.  docker run --name springboot -p 8080:8080 springbootmaven  
  7.  docker run --name springboot -d -p 8080:8080 springbootmaven  
  8. カール http://localhost:8080

ここで、apk add curl コマンドをもう一度実行してみます。

  1. シェル
  2. docker exec -it springboot /bin/sh
  3.  apk追加カール

つまり、apk の依存関係は正常に解消され、アプリケーションは正常に実行されました。

Alpine OS を強化するために特別に作成された優れたスクリプトをいくつか紹介します。プログラミング言語に基づいて選択し、それに応じてベースのアルパイン イメージを強化します。参考URLをいくつか紹介します。

  • https://gist.github.com/kost/017e95aa24f454f77a37
  • https://github.com/ironpeakservices/iron-alpine/blob/master/Dockerfile

一方、Google が作成した distroless コンテナもチェックしてみると良いでしょう。これも強くお勧めします。

  • https://github.com/GoogleContainerTools/distroless/tree/main/examples

（２）ユーザーシナリオの切り替え

サイバー攻撃者がコンテナ内で RCE を取得した場合、curl、wget などのパッケージをインストールして永続性を確立できなくなる可能性があると主張する人もいます。

ただし、引き続き「root」ユーザーとして実行している場合は、技術的には apk を再インストールすることは可能です。

ここで Docker コンテナを再実行し、現在実行されている権限を確認します。

  1. シェル
  2. docker exec -it springboot /bin/sh
  3. だれだ
  4. rohitsalecha.com にピン

したがって、コンテナを root として実行するのではなく、制限された権限のみを持つユーザーとして実行することが重要です。

Dockerfile.lpr には、「boot」というユーザーとグループを追加し、作業ディレクトリ (ホーム ディレクトリ) を割り当てるコマンドが追加されています。ユーザーとグループには数値も割り当てられます。これについては、以下の「ポッド セキュリティ シナリオ」セクションで詳しく説明します。

  1.  Dockerファイル
  2. maven:3.8.1-openjdk-17-slimからMAVEN_BUILDとして
  3. ワークディレクトリ /build/
  4.  pom.xml /build/ をコピーします。
  5. コピー src /build/src/
  6.  mvnパッケージを実行する
  8. openjdk:17-alpineより
  10. # apk パッケージ マネージャーを削除する
  11. 実行rm -f /sbin/apk && \
  12.  rm -rf /etc/apk && \
  13.  rm -rf /lib/apk && \
  14.  rm -rf /usr/share/apk && \
  15.  rm -rf rm -rf /var/lib/apk 
  16.  
  17.  #ユーザーの追加 そして  「ブート」と呼ばれるグループ 
  18.  addgroup boot -g 1337 && \ を実行します。
  19.  adduser -D -h /home/boot -u 1337 -s /bin/ash ブート -G ブート
  20.  
  21.  # 以下のコマンドを実行するコンテキストを変更する ユーザー  "ブート"  その代わり ルートの
  22. ユーザーブート
  23. ワークディレクトリ /home/boot
  25.  ＃による デフォルトでは、非ルート コンテキストでも、Docker はファイルをルートとしてコピーします。したがって、 chownするのがベストプラクティスです
  26. #ユーザーとしてコピーされるファイル。 https://stackoverflow.com/a/44766666/1679541
  27. コピー--chown=boot:boot --from=MAVEN_BUILD /build/target/springbootmaven.jar /home/boot/springbootmaven.jar  
  28. エクスポーズ8080
  29. コマンド java -jar /home/boot/springbootmaven.jar

再構築して再実行:

  1.  #まず、以前実行していたコンテナを停止しましょう
  2. docker の springboot を停止する
  3. #次に再構築して再実行してみましょう
  4. docker ビルド 。 -f Dockerfile.lpr -t springbootmaven docker run --name springboot -d -p 8080:8080 springbootmaven curl http://localhost:8080  

次に、whoami コマンドを実行して、どのコンテナが現在どの権限で実行されているかを確認します。

  1. シェル
  2. docker exec -it springboot /bin/sh
  3. だれだ
  4. rohitsalecha.com にピン

ランタイムセキュリティ

パッケージが削除され、ユーザー シナリオが更新されて権限が制限されたコンテナーが実行されるようになったため、ビルド時のセキュリティに対する信頼が高まっています。これらのセキュリティ機能は、Docker コンテナを構築するときに適用されます。ただし、Kubernetes 環境でコンテナを実行する場合は、コンテナのセキュリティ体制にも重点を置く必要があります。これについては、以下で説明します。

Kubernetes デプロイメントのセキュリティ保護を開始する前に、まず Docker コンテナを hub.docker.com にプッシュして、Kubernetes クラスター上でアプリケーションを実行します。このガイドを使用して、同じことを始めることができます。

  1. シェル
  2. docker ビルド 。 -f Dockerfile.lpr -t springbootmaven
  3.  docker タグ springbootmaven salecharohit/springbootmaven
  4.  docker push salecharohit/springbootmaven
  5.  docker run -d -p 8080:8080 --name springboot salecharohit/springbootmaven  
  6. カール http://localhost:8080

Docker イメージの準備ができたので、kubernetes-basic.yaml ファイルを適用して、このアプリケーションと、それに接続するのに役立つサービスをデプロイします。

  1. ヤム
  2. #名前空間を作成する
  3. APIバージョン: v1
  4. 種類: 名前空間
  5. メタデータ:
  6. 名前: ブート
  8. ---  
  9.  # SpringBootデプロイメントを作成する
  10. APIバージョン: アプリ/v1
  11. 種類: デプロイメント
  12. メタデータ:
  13. ラベル:
  14. アプリ: springbootmaven
  15. 名前: springbootmaven
  16. 名前空間: ブート
  17. 仕様:
  18. レプリカ: 1
  19. セレクタ：
  20. 一致ラベル:
  21. アプリ: springbootmaven
  22. テンプレート：
  23. メタデータ:
  24. ラベル:
  25.  アプリ: springbootmaven
  26. 仕様:
  27. コンテナ:
  28.  - 画像: salecharohit/springbootmaven
  29. 名前: springbootmaven
  30.  ポート:
  31.  - コンテナポート: 8080 
  32.  
  33.  ---  
  34.  # SpringBoot デプロイメント用のサービスを作成する
  35. APIバージョン: v1
  36. 種類: サービス
  37. メタデータ:
  38.  ラベル:
  39.  アプリ: springbootmaven
  40. 名前: springbootmaven
  41. 名前空間: ブート
  42. 仕様:
  43. ポート:
  44.  -名前: "http"  
  45. ポート: 8080
  46. ターゲットポート: 8080
  47. セレクタ：
  48. アプリ: springbootmaven

Pod が Kubernetes API サーバーと通信する必要がある場合、認証にはサービス アカウント トークンが必要です。

  1. シェル
  2. kubectl を適用 -f kubernetes-basic.yaml
  3.  kubectl get deploy -n ブート
  4. #ブートサービスのみをcurl する一時コンテナを実行します
  5. kubectl run -it testpod --image=radial/busyboxplus:curl --restart=Never --rm -- curl http://springbootmaven.boot.svc.cluster.local:8080  
  7. 期待される出力:
  8.  Alpine OSでMaven を使用して Spring Boot ビルドからHello World を実行しました。pod "testpod"が削除されました

（1）サービスアカウントトークン

Pod が Kubernetes API サーバーと通信する必要がある場合、認証用のサービス アカウント トークンが必要です。

デフォルトでは、各 Pod には /var/run/secrets/kubernetes.io/serviceaccount/token にマウントされるサービス アカウント トークンが割り当てられます。 Spring Boot アプリケーションをデプロイすると、これを実際に確認できます。

  1. シェル
  2. kubectl ポッドを取得 -n ブート
  3. kubectl exec -it springbootmaven-7d7c5c8597-mndv9 -n ブート-- /bin/sh  
  4. トークン=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
  5.  curl -k -H "Authorization:Bearer $TOKEN" https://kubernetes.docker.internal:6443/version

アプリケーションに RCE 脆弱性があると、このアクセス トークンがネットワーク攻撃者に漏洩する可能性があります。攻撃者は、グローバル読み取り権限があっても、このアクセス トークンを悪用して同じ名前空間内のリソースの読み取りと書き込みを行うことができます。

この問題には、具体的な状況に応じて 2 つの解決策があります。まず、Pod は API サーバーにアクセスする必要はありません。次に、Pod は API サーバーにアクセスする必要があります。

  • APIサーバーにアクセスする必要のないポッド

この状況は、次に示すように、Kubernetes マニフェスト ファイルに 2 行を追加することで簡単に修正できます。

  1. ヤム
  2. 1 サービス アカウント名: ""  
  3.  2 automountServiceAccountToken: false  

完全なデプロイメント ファイル kubernetes-nosa.yaml は次のとおりです。

  1. ヤム
  2. APIバージョン: アプリ/v1
  3. 種類: デプロイメント
  4. メタデータ:
  5. ラベル:
  6. アプリ: springbootmaven
  7. 名前: springbootmaven
  8. 名前空間: ブート
  9. 仕様:
  10. レプリカ: 1
  11. セレクタ：
  12. 一致ラベル:
  13. アプリ: springbootmaven
  14. テンプレート：
  15. メタデータ:
  16. ラベル:
  17. アプリ: springbootmaven
  18. 仕様:
  19. コンテナ:
  20. 画像: salecharohit/springbootmaven
  21. 名前: springbootmaven
  22. ポート:
  23.  - コンテナポート: 8080
  24. サービスアカウント名: ""  
  25.  automountServiceAccountToken: false    

次に、サービス アカウント トークンがインストールされていることを確認します。

  1. シェル
  2. # 以前のデプロイが削除されていることを確認します。
  3.  kubectl ns ブートを削除する
  5. # 応募する サービス アカウント トークンがありません
  6. kubectl を適用 -f kubernetes-nosa.yaml
  7.  kubectl ポッドを取得 -n ブート
  8. kubectl exec -it springbootmaven-5568b9874f-8nml8 -n ブート-- /bin/sh  
  9.  cat /var/run/secrets/kubernetes.io/serviceaccount/token

上記のように、デフォルトのサービス アカウント トークンはマウントされなくなりました。

  • APIサーバーにアクセスする必要があるポッド

この場合、ServiceAccount をロールにマップする ServiceAccount、Role、および RoleBinding を作成する必要があります。 Kubernetes チェックリストは次のとおりです。

  • 特定の名前空間 (つまり boot) に対して bootserviceaccount という名前の ServiceAccount を作成します。
  • 実行中の Pod を表示する権限のみを持つ bootservicerole というロールを作成します。
  • bootservicerolebinding という名前の RoleBinding を作成します。
  • 次の行を使用して、作成された ServiceAccount をデプロイメントにマウントします。
  1. ヤム
  2. ---  
  3. 仕様:
  4. コンテナ:
  5.  - 画像: salecharohit/springbootmaven
  6. 名前: springbootmaven
  7. ポート:
  8.  - コンテナポート: 8080
  9.  サービスアカウント名: bootserviceaccount
  10.  ---  

これにより、「boot」名前空間内の Pod のみの読み取りが可能になります。

完全なデプロイメント ファイル kubernetes-withsa.yaml は次のとおりです。

  1. ヤム
  2. #名前空間を作成する
  3. APIバージョン: v1
  4. 種類: 名前空間
  5. メタデータ:
  6. 名前: ブート
  8. ---  
  9.  APIバージョン: v1
  10. 種類: サービスアカウント
  11. メタデータ:
  12. 名前: bootserviceaccount
  13. 名前空間: ブート
  15. ---  
  16. 種類: 役割
  17. apiバージョン: rbac。認証.k8s.io/v1
  18. メタデータ:
  19. 名前: bootservicerole
  20. 名前空間: ブート
  21. ルール:
  22.  -apiグループ: [ "" ]
  23. リソース: [ "ポッド" ]
  24. 動詞: [ 「取得する」 、 「一覧表示する」 、 「見る」 ]
  26.  ---  
  27. 種類: RoleBinding
  28.  apiバージョン: rbac。認証.k8s.io/v1
  29. メタデータ:
  30. 名前: bootservicerolebinding
  31. 名前空間: ブート
  32. 科目:
  33.  - 種類: サービスアカウント
  34. 名前: bootserviceaccount
  35. 名前空間: ブート
  36. ロールリファレンス:
  37. 種類: 役割
  38. 名前: bootservicerole
  39.  apiGroup : rbac.authorization.k8s.io
  41.  ---  
  42.  # SpringBootデプロイメントを作成する
  43. APIバージョン: アプリ/v1
  44. 種類: デプロイメント
  45. メタデータ:
  46. ラベル:
  47. アプリ: springbootmaven
  48. 名前: springbootmaven
  49. 名前空間: ブート
  50. 仕様:
  51. レプリカ: 1
  52. セレクタ：
  53. 一致ラベル:
  54. アプリ: springbootmaven
  55. テンプレート：
  56. メタデータ:
  57. ラベル:
  58. アプリ: springbootmaven
  59. 仕様:
  60. コンテナ:
  61.  - 画像: salecharohit/springbootmaven
  62. 名前: springbootmaven
  63. ポート:
  64.  - コンテナポート: 8080
  65. サービスアカウント名: bootserviceaccount 
  66.  
  67.  ---  
  68.  # SpringBoot デプロイメント用のサービスを作成する
  69. APIバージョン: v1
  70. 種類: サービス
  71. メタデータ:
  72. ラベル:
  73. アプリ: springbootmaven
  74. 名前: springbootmaven
  75. 名前空間: ブート
  76. 仕様:
  77. ポート:
  78.  -名前: "http"  
  79. ポート: 8080
  80. ターゲットポート: 8080
  81. セレクタ：
  82. アプリ: springbootmaven

次に実行して、アプリケーションが正常に実行されるかどうかを確認します。

  1.  # 以前のデプロイが削除されていることを確認します。
  2.  kubectl ns ブートを削除する
  3. kubectl を適用 -f kubernetes-withsa.yaml
  4.  kubectl run -it testpod --image=radial/busyboxplus:curl --restart=Never --rm -- curl http://springbootmaven.boot.svc.cluster.local:8080  

# 以前のデプロイメントを必ず削除してください。

（２）ポッドセキュリティシナリオ

基本 Docker イメージは非ルート権限で実行するように構成されていますが、セキュリティのベスト プラクティスとして、少量の構成を追加する必要があります。したがって、次のことを行う必要があります。

① コンテナとポッドの機能を制限します。

②権限昇格を無効にします。

③Dockerfile.lpr で先ほど作成した特定の uid/gid でコンテナを実行するように設定します。

Kubernetes マニフェスト ファイルでは、2 種類の「SecurityContexts」が定義されています。

  • ポッドレベルで実行します。これは、このポッドで実行されているすべてのコンテナに適用されます。
  1. ヤム
  2. ---  
  3. セキュリティコンテキスト:
  4. グループ: 1337
  5. 非ルートとして実行: true  
  6. 実行ユーザー: 1337
  7. コンテナ:
  8.  ---  
  • コンテナレベルで実行
  1. ヤム
  2. ---  
  3. セキュリティコンテキスト:
  4. 権限昇格を許可: false  
  5. 特権: false  
  6. 実行ユーザー: 1337
  7. 機能:
  8. ドロップ: [ "SETUID" , "SETGID" ]
  9. サービスアカウント名: ""  
  10.  automountServiceAccountToken: false  
  11.  ---  

PodSecurity シナリオを埋め込む完全なデプロイメント ファイル kubernetes-ps.yaml は次のとおりです。

  1. ヤム
  2. #名前空間を作成する
  3. APIバージョン: v1
  4. 種類: 名前空間
  5. メタデータ:
  6. 名前: ブート
  7. ---  
  8.  # SpringBootデプロイメントを作成する
  9. APIバージョン: アプリ/v1
  10. 種類: デプロイメント
  11. メタデータ:
  12. ラベル:
  13. アプリ: springbootmaven
  14. 名前: springbootmaven
  15. 名前空間: ブート
  16. 仕様:
  17. レプリカ: 1
  18. セレクタ：
  19. 一致ラベル:
  20. アプリ: springbootmaven
  21. テンプレート：
  22. メタデータ:
  23. ラベル:
  24. アプリ: springbootmaven
  25. 仕様:
  26. セキュリティコンテキスト:
  27. グループ: 1337
  28. 非ルートとして実行: true  
  29. 実行ユーザー: 1337
  30.  コンテナ:
  31.  - 画像: salecharohit/springbootmaven
  32. 名前: springbootmaven
  33. ポート:
  34.  - コンテナポート: 8080
  35. セキュリティコンテキスト:
  36. 権限昇格を許可: false  
  37. 特権: false  
  38. 実行ユーザー: 1337
  39. 機能:
  40. ドロップ: [ "SETUID" , "SETGID" ]
  41. サービスアカウント名: ""  
  42.  automountServiceAccountToken: false  
  43.  ---  
  44.  # SpringBoot デプロイメント用のサービスを作成する
  45. APIバージョン: v1
  46. 種類: サービス
  47. メタデータ:
  48. ラベル:
  49.  アプリ: springbootmaven
  50. 名前: springbootmaven
  51. 名前空間: ブート
  52. 仕様:
  53. ポート:
  54.  -名前: "http"  
  55. ポート: 8080
  56. ターゲットポート: 8080
  57. セレクタ：
  58. アプリ: springbootmaven

実行して、アプリケーションが実行されていることをテストします。

  1. シェル
  2. # 前回の適用が削除されていることを確認する
  3. kubectl ns ブートを削除する
  4. kubectl を適用 -f kubernetes-ps.yaml
  5.  kubectl run -it testpod --image=radial/busyboxplus:curl --restart=Never --rm -- curl http://springbootmaven.boot.svc.cluster.local:8080  
  6.  kubectl ポッドを取得 -n ブート
  7. kubectl exec -it springbootmaven-56c64ff85-mqz2z -n ブート-- /bin/sh  
  8. だれだ
  9. id
  10.  google.com にping

開発者はニーズに応じてさらに多くの機能を削除できます。

AppArmor や SecComp などの機能では、コントロール プレーン コンポーネントの追加構成が必要です。したがって、ここで説明する内容は、簡単に有効化でき、高いレベルのセキュリティ保証を保証する、すぐに使用できる機能に限定されます。

（３）不変ファイルシステム

コンテナ化された環境で実行されるアプリケーションは、実際には不変のシステムを持つというロジックに反するため、データを書き込むことはほとんどありません。ただし、場合によってはファイルをキャッシュしたり、一時的にスワップ/処理したりする必要があることもあります。したがって、開発者にこの機能を提供するために、コンテナが強制終了されると失われる一時ボリュームとして emptyDir をマウントすることができます。

これにより、コンテナー内で実行されているアプリケーションは、「tmp」ディレクトリ以外のファイル システムのどこにも書き込む必要がなくなるため、「readOnlyRootFilesystem」という別のセキュリティ シナリオ プロパティを追加して true に設定することもできます。

上記の要件は以下のように設定できます。

  1. ヤム
  2. ---  
  3. コンテナ:
  4.  - 画像: salecharohit/springbootmaven
  5. 名前: springbootmaven
  6. ポート:
  7.  - コンテナポート: 8080
  8. セキュリティコンテキスト:
  9.  readOnlyRootFilesystem: true  
  10. ボリュームマウント:
  11.  - マウントパス: /tmp
  12. 名前: tmp
  13. ボリューム:
  14.  - 空のディレクトリ: {}
  15. 名前: tmp
  16.  ---  

完全なデプロイメント ファイル kubernetes-rofs.yaml は次のコードに示されています。

  1. ヤム
  2. #名前空間を作成する
  3. APIバージョン: v1
  4. 種類: 名前空間
  5. メタデータ:
  6. 名前: ブート
  7. ---  
  8.  # SpringBootデプロイメントを作成する
  9. APIバージョン: アプリ/v1
  10. 種類: デプロイメント
  11.  メタデータ:
  12. ラベル:
  13. アプリ: springbootmaven
  14. 名前: springbootmaven
  15. 名前空間: ブート
  16. 仕様:
  17. レプリカ: 1
  18. セレクタ：
  19. 一致ラベル:
  20. アプリ: springbootmaven
  21. テンプレート：
  22. メタデータ:
  23. ラベル:
  24. アプリ: springbootmaven
  25. 仕様:
  26. セキュリティコンテキスト:
  27. グループ: 1337
  28. 非ルートとして実行: true  
  29. 実行ユーザー: 1337
  30. コンテナ:
  31.  - 画像: salecharohit/springbootmaven
  32. 名前: springbootmaven
  33. ポート:
  34.  - コンテナポート: 8080
  35. セキュリティコンテキスト:
  36. 権限昇格を許可: false  
  37.  readOnlyRootFilesystem: true  
  38. 特権: false  
  39. 実行ユーザー: 1337
  40. 機能:
  41. ドロップ: [ "SETUID" , "SETGID" ]
  42. ボリュームマウント:
  43.  - マウントパス: /tmp
  44. 名前: tmp
  45. サービスアカウント名: ""  
  46.  automountServiceAccountToken: false  
  47.  ボリューム:
  48.  - 空のディレクトリ: {}
  49. 名前: tmp
  51.  ---  
  52.  # SpringBoot デプロイメント用のサービスを作成する
  53. APIバージョン: v1
  54. 種類: サービス
  55. メタデータ:
  56. ラベル:
  57. アプリ: springbootmaven
  58. 名前: springbootmaven
  59. 名前空間: ブート
  60. 仕様:
  61. ポート:
  62.  -名前: "http"  
  63. ポート: 8080
  64. ターゲットポート: 8080
  65. セレクタ：
  66. アプリ: springbootmaven

アプリケーションを起動し、アプリケーションが実行されているかどうかをテストします。

  1. シェル
  2. # 前回の適用が削除されていることを確認する
  3. kubectl ns ブートを削除する
  4. kubectl を適用 -f kubernetes-rofs.yaml
  5.  kubectl run -it testpod --image=radial/busyboxplus:curl --restart=Never --rm -- curl http://springbootmaven.boot.svc.cluster.local:8080  
  6.  kubectl ポッドを取得 -n ブート
  7. kubectl exec -it springbootmaven-56c64ff85-mqz2z -n ブート-- /bin/sh  
  8. パスワード
  9. タッチテスト.txt

結論は

これで、コンテナ化されたアプリケーションに埋め込むことができるさまざまなコントロールがわかりました。また、サイバー攻撃者がコンテナ化されたシステムに足場を築くことを困難にするランタイム保護メカニズムを有効にする方法も理解します。

kubernetes-rofs.yaml は、Kubernetes 環境にデプロイされたときに、開発者がデフォルトのセキュリティ機能を使用してアプリケーションをコンテナ化するための優れたテンプレートとして機能します。

もちろん、特定のアプリケーション用の Dockerfile を作成する必要があります。

原題: Kubernetes デプロイメントにおけるブートストラップ セキュリティ、著者: Rohit Salecha

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。

<<:  「アプリケーションイノベーション」の精神を示し、「インテリジェント製造統合」のトレンドを創造する――「長高新カップ」第1回ファーウェイクラウド全国産業インターネットアプリケーションイノベーションコンテスト決勝戦がまもなく開幕

>>:  きっとあなたは理解していないでしょう: 分散ストレージ システムにおける強力なデータ一貫性の課題

推薦する

SEOにおけるnofollowタグの属性と機能の包括的な分析

この記事では、nofollow タグの使い方と書き方を 5 つの知識ポイントから総合的に分析します。...

5Gとエッジコンピューティングの業界間コラボレーションの探求

5G ネットワークとエッジ コンピューティングの組み合わせにより、業界横断的な変革の時代が到来しまし...

QingCloud Technologyは新しい外観と新しい企業ブランドで9周年を迎えます

ハイブリッドクラウドの先駆者でありリーダーであるQingCloud Technology（証券コード...

Henghost: 香港CN2 GIAラインVPSの簡単なレビュー、実際のテストデータからHenghostがいかに優れているかがわかる

henghost（恒創科技）は、香港、韓国、日本、米国でクラウドサーバーと独立サーバー事業を運営し、...

タオバオストアレビューウェブサイトを3か月間運営した経験

タオバオアフィリエイトは2009年に登場しました。安定性、収益性、評判の良さ、プロモーション方法の多...

#blackfriday# hostgator - 80% オフ、無制限のウェブサイト構築、仮想ホスティング/VPS/サーバー

アメリカの有名ホスティングブランド、Hostgatorのブラックフライデープロモーションが始まりまし...

草の根トーク：「ペニーペニー」のさまざまなウェブサイト最適化手法

SEO はウェブサイトのプロモーションの同義語の 1 つになっているようです。さまざまな種類のウェブ...

新浪ブログの外部リンクが表示されない理由を明かす

ほとんどのSEO担当者は、外部リンクをサードパーティのブログに張る際にSina Blogを第一候補に...

ハイブリッド クラウドの旅は Linux から始まります。

今日の時代では、組織は顧客に価値を提供する方法を変革するために、新しいテクノロジーと実践に継続的に投...

5G 時代では、エッジ コンピューティングが「コア」コンピューティングに取って代わるのでしょうか?

「最近5Gが大人気ですが、なぜでしょうか？最近、あなたの周りでも5Gについて話している人が多いですか...

「ブランド効果の統合」はインターネット広告を台無しにしたのか？

広告業界やマーケティング業界では、ブランド効果の統合に関してさまざまな見解があり、それぞれ独自の意見...

ホームページのフォーカス画像の色合わせについて――黒

電子商取引に携わる人は、装飾の重要性を知っています。私はよくオンラインストアを女性に例えます。店舗の...

ウェブサイトの実際のコンテンツは最適化の重要な要素です

SEOに精通検索エンジン最適化 (SEO) とは、ウェブサイトの構造、ウェブページのコード、コンテン...

分散クラウドコンピューティングとデータガバナンスの詳細な説明

さまざまな種類のデータが複数のデータ チャネルを通じてリアルタイムで大量に流入し始めると、データ管理...

2013 年に Baidu の最適化がますます困難になっているのはなぜでしょうか? 何をすべきでしょうか?

個人的には、現在ウェブサイトの最適化を行う人々は 2 つのカテゴリに分けられると考えています。1 つ...