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回ファーウェイクラウド全国産業インターネットアプリケーションイノベーションコンテスト決勝戦がまもなく開幕

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

推薦する

新しいウェブサイトの最適化のボトルネックを打破するためのいくつかの提案

新規サイトの企画から仮説までのプロセスは比較的単純で、運営上の難しさはサイトの最適化にあります。現在...

上級データベースエンジニアに必要なスキル

いわゆる DBA は、通常データベース管理者と呼ばれるもので、主にデータベースのインストール、管理、...

Microsoft Dynamics 365: CRM と ERP にとどまらず、次世代のインテリジェント ビジネス アプリケーションを再定義

2019年5月6日より、21Vianetが運営するMicrosoft Dynamics 365（「D...

推奨: tmzvps、高品質の VPS 販売業者、明らかなネットワーク最適化、優れたアフターサービス

海外で非常に評判の良いtmzvpsを紹介します。価格が比較的高いため、多くの中国人はそれに触れたこと...

クラウドコンピューティング時代のデータベース運用について簡単に解説

これまで、企業が災害復旧 (DR) インフラストラクチャを構築したい場合、それはスタンドアロンの施設...

VMware の Ye Yujian: 製品を統合して完全な SASE ソリューションを構築し、企業のリモート ワークを実現

[51CTO.comからのオリジナル記事]ポストエピデミック時代において、リモートワークは新たな常態...

検索エンジン最適化におけるウェブサイトのコンテンツ、構造、キーワードについて

検索エンジン最適化（SEO）は非常に奥が深いテーマであり、新しい技術や新しいエンジンアルゴリズムの影...

hostkvm: Tri-Network US cn2 vps、30% 割引、月額 6 ドル、2G メモリ/1 コア/25g ハード ドライブ/1T トラフィック

Hostkvm は、米国の cn2 VPS をリリースしました。3 つのネットワーク (China ...

budgetnode がメモリを 2 倍に、年間 12 ドルで 512MB メモリ、Voxility が DDoS 保護を無料で提供

budgetnode.com は、プロモーションを記念して、同じ価格でメモリを 2 倍にした新しいア...

net2hosting $9.95/年 有料ウェブホスティング

net2hosting は新しいホスティング プロバイダーです。10 ドルを支払っても構わないなら、...

キーワードのランキングは1日に3回変わります。SEOを安定させるにはどうすればいいでしょうか?

みなさんこんにちは。私は徐子宇です。百度は最近、アルゴリズムを調整している。6月22日と28日に低品...

Huyaは「安定を維持」、Douyuは「自らを救う」

ゲームライブストリーミング業界の大きな出来事といえば、DouyuとHuyaの「一時的な和解」に触れな...

ウェブサイト内部からのユーザーエクスペリエンス最適化の重要なポイントをいくつかお話ししましょう。

2012年、Baiduからさまざまなアップデートがありました。SEOがなければ、ユーザーをどのように...

鉄道省のチケット予約ウェブサイトのトラフィックが急増し、世界第11位の電子商取引ウェブサイトに

写真は過去3か月間のAlexaランキング12306の成長を示しています新浪科技は1月5日夜、鉄道部が...

フォーラム外部リンクマイニング: フォーラム外部リンクをより効果的に構築する方法

フォーラムの外部リンクは非常に早い段階で発見され、その後広く使用されました。その結果、一部のフォーラ...