ry's Tech blog

Cloud Native技術などについて書いていきます。

Kubenews #35

2021-10-15

How to Start your Cloud Security Journey (click here to source)

クラウドセキュリティの旅を始める上で重要な重点分野のいくつかは次のとおりです。

  • 脅威モデリング
  • セキュリティの設定ミスの修正
  • ネットワークアクセス
  • クラウドリソースへのアクセスの改善
  • IAMポリシーの保護
  • ロギングとモニタリングの実装

脅威モデリング

脅威モデリングは、脅威を特定し、システムへの脅威を防止または軽減するための対策を定義するプロセスです。

脅威のモデリングに関連する手順:

  1. アーキテクチャ図を作成する
  2. 脅威を特定する
  3. 軽減する
  4. 検証

セキュリティ設定ミスの修正

このレポートによると、クラウド脆弱性の95%以上がクラウドの構成ミスに関連しています。

Prowler

Prowlerは、AWSのみに対応しており、クラウドセキュリティの設定ミスを特定するのに役立つオープンソースのセキュリティ監査ツールです。

主な機能として、クラウドアカウントのセキュリティの脆弱性のリストを提供します。

調査結果をHTML、CSVJSON、またはjson-asff形式でエクスポートできます。

Prowlerは、AWS Security Hubと統合することが可能です。

Security Hubを使用すると、Prowlerだけでなく、AWS GuardDuty、Inspector、Macieなどの複数のAWSサービスからのセキュリティアラートまたは検出結果を集約、整理、および優先順位付けすることが可能です。

ネットワークアクセス

クラウド環境のアーキテクチャを評価するには、ネットワーク図が必要です。

CloudMapper

CloudMapperは、アマゾンウェブサービスAWS)環境の分析に役立ちます。

ネットワーク図の作成を支援し、ブラウザに表示します。

ネットワークセグメンテーション

ネットワークセグメンテーションを実装することにより、ネットワークの攻撃対象領域を減らします。

フェイルオープンではなく、フェイルセーフネットワークアクセスアプローチを採用することを検討してください。

  • フェイルセーフ
    • 操作方法を間違ったり、部品が壊れたり、誤作動したりした場合に、危ない方向ではなく、安全な方向へ向かうように設計すること

クラウドリソースへのアクセスの改善

クラウドリソースへの接続には、安全でプライベートなアクセスが必要です。

これを実現するために様々な方法があります。

  • VPNセットアップ
  • bastion/Jump Box
  • KeycloakやTeleportなどの中央認証システム
  • AWS SSM

IAMポリシーの保護

ユーザーアクセスポリシー(IAMポリシー)は、クラウドインフラストラクチャを保護するのに役立つもう1つのコアコントロールです。

IAMポリシーの周囲に適切なセキュリティ衛生を設けることで、違反が発生した場合に攻撃者が広範囲の損害を与える可能性を減らすことができます。

実装を検討する必要があるいくつかのIAMコントロール

  • クラウドアカウントのrootユーザーアクセスキーをロックする
  • 個々のIAMユーザーを作成する
  • ユーザーグループを使用して、IAMユーザーにアクセス許可を割り当てます
  • 最小特権を付与する
  • ユーザーに強力なパスワードポリシーを構成する
  • MFAを有効にする
  • Roleを使用して権限を委任する
  • アクセスキーを共有しない
  • クレデンシャルを定期的にローテーションする
  • 不要なクレデンシャルを削除する
  • クラウドアカウントのアクティビティを監視する

policy_sentryなどのツールを使用して、最小特権のIAMポリシーを作成することもできます。

セキュリティのログ記録と監視

セキュリティのログ記録と監視は、クラウド環境で何が悪かったのかを特定するのに役立ち、悪意のあるイベントを発見できる唯一の方法です。

手始めに、少なくともすべてのリージョンでCloudtrailを有効にして、クラウドストレージに配置することができます。

次に、複数の認証の拒否や特権の昇格の失敗など、一般的なセキュリティのユースケースに対してアラートを設定する必要があります。

APIコールログ(Cloudtrail)、DNSログ(Route53)、ネットワークアクセスログVPCフローログ)、クラウドストレージログ(S3)、Security Hub、GuardDuty、WAFログ、アプリケーションログなどのセキュリティサービスログは、検出ルールを構築するためにログに記録する必要があります。

長期保存用に個別のログアカウントを持ち、一元化された監視アカウントを持ち、ElasticsearchなどのSIEMにデータを送信することをお勧めします。

micro-lc: a new open-source project for micro frontend orchestration (click here to source)

マイクロフロントエンド:それらは何であり、何のために必要ですか?

アプリケーションの開発を簡素化および高速化できることから人気が高まっているマイクロサービスのアーキテクチャパターンと同じようなものとして、マイクロフロントエンド が生まれ、 マイクロサービスがバックエンドに対して実行するのと同様のデカップリングロジックをフロントエンドに適用します。

これにより、フロントエンドアプリケーションを一連の再利用可能なモジュラーコンポーネントに分解することや、新しいフロントエンド機能リリースの敏捷性を向上させることができます。

micro-lc:特性と利点

micro-lcは、Mia‑Platformによって作成されたマイクロフロントエンドオーケストレーションコンポーネントであり、開発エクスペリエンスの一貫性を保つことができます 。

すべてのバックエンドとフロントエンドのパーツが含まれており、プラグインを介してそれらを拡張できます。

フロントエンド

フロントエンドは、 各々が接続されたフロントエンドを構成するために使用することができる一連のクロスアプリケーション機能を提供するContainerから構成されます。

機能としては以下のようなものがあります。

  • レイアウトの基本要素、
    • トップバーとメニュー(サイドバーメニュー、折りたたみ可能なサイドバーメニュー、トップバーメニューの3種類)
  • アプリケーションの色
  • ロゴとファビコン
  • ウィンドウタイトル
  • ダークモード/ライトモード
  • ユーザーデータ
  • グーグルアナリティクス
  • プラグイン管理

バックエンド

バックエンドでは、フロントエンドの要素を定義する要素、ユーザー認証、また一般的な構成を管理できます。

micro-lcは、ユーザーを直接管理または認証をせず、認証エンドポイントを構成でき、認証エンドポイントは、認証プロバイダーによって管理されます。

Kubenews #33

2021-10-01

IAM roles for Kubernetes service accounts - deep dive (click here to source)

「ServiceAccountのCredentialを用いて、Podの中からAWSのサービスにアクセスする方法」に関して、OpenID Connectの例を交えながら説明してくれている記事です。

Top Open Source CI/CD Tools for Kubernetes to Know (click here to source)

Open SourceのCI/CDツールの中で、人気なツールを選抜してPros&Consを交えながら紹介してくれています。

  • Tekton
  • Argo
  • GitHub Actions
  • Jenkins X
  • OpenShift Pipelines
  • Spinnaker
  • Circle CI
  • GitLab CI

How Chaos Mesh helps Apache APISIX improve system stability (click here to source)

Apache APISIX (github)というAPI Gatewayを用いた環境において、Chaos mesh (github)を用いてシステムの安定性を向上させる方法が紹介されています。

課題

Apache APISIXは、1日に数百億のリクエストを処理します。

その中で気づいた課題が以下の2点でした。

  1. Apache APISIXの構成センターで、etcdとApache APISIXの間で予期しない高いネットワーク遅延が発生した場合でも、Apache APISIXはトラフィックを正常にフィルタリングして転送できるのだろうか。
  2. etcdクラスター内のノードに障害が発生し、クラスターが引き続き正常に実行できる場合においても、ノードとApache APISIX管理APIとのインタラクションに関するエラーが報告されてしまう。

Apache APISIXは、ユニット、エンドツーエンド(E2E)、および継続的インテグレーション(CI)でのテストを通じて多くのシナリオをカバーすることができました。

ただ、外部コンポーネントとの相互作用シナリオはカバーしていません。

ネットワークがジッターしたり、ハードディスクに障害が発生したり、プロセスが強制終了したりした場合など、システムが異常に動作する場合、Apache APISIXは適切なエラーメッセージを表示できますか?実行を継続することはできますか、それとも通常の操作に戻すことができますか?ということを検証しきれていませんでした。

カオスメッシュを選んだ理由

Chaos Meshは、クラウドネイティブなChaos Engineeringプラットフォームであり、Kubernetes上の複雑なシステム向けのオールラウンドなフォールトインジェクション手法を備えており、ポッド、ネットワーク、ファイルシステム、さらにはカーネルのフォールトをカバーします。

この機能によって、ユーザーがシステムの弱点を見つけるのに役立つ上に、システムが実稼働環境において制御不能な状況になった際の対応ができるようになります。

APISIX配下でカオスメッシュを使用する方法

前述の2つの課題に対する。

課題1

次の手順を使用して、カオスエンジニアリング実験を展開しました。

[1]

ApacheAPISIXが正常に実行されているかどうかを測定するためのメトリックが見つけることができました。

Grafanaを使用してApacheAPISIXの実行中のメトリックを監視した。

比較のために、CIにおいてPrometheusからデータを抽出しました。

ここでは、1秒あたりのルーティングおよび転送要求(RPS)とetcd接続を評価メトリックとして使用しました。

加えてログを分析しました。

Apache APISIXの場合、Nginxのエラーログをチェックして、エラーが発生したかどうか、およびエラーが予想どおりであったかどうかを判断しました。

[2]

Control Groupにおける試験を行いました。

私たちはcreate route と access routeの両方が成功していること、そしてetcdに接続することができるというのがわかりました。

そしてRPSを記録しました。

[3]

ネットワークカオスを使用して5秒のネットワーク遅延を追加し、再テストしました。

今回、 set routeが失敗し、 get routeが成功でき、etcdに接続でき、RPSは前の実験と比較して大きな変化はないという結果でした。

実験は私たちの期待に沿う形となった。

課題2

上の検証をした際に、ポッドキルカオスを導入して、予想されるエラーを再現しました。

クラスタ内の少数のetcdノードをランダムに削除したところ、APISIXがetcdに接続できる場合と接続できない場合があり、ログに多数の接続拒否エラーが出力されました。

etcdエンドポイントリストの最初または3番目のノードを削除すると、set route に対して正常な結果が返されたのに対し、リストの2番目のノードを削除すると、set route に対して「接続が拒否されました」というエラーが 返されました。

原因としては、Apache APISIXで使用されるetcd Lua APIが、ランダムではなく順次エンドポイントを選択していました。

結果としてetcdクライアントを作成した際に、1つのetcdエンドポイントのみにバインドされてしまい、これが継続的な失敗につながりました。

対応として、etcd Lua APIにヘルスチェックを追加して、切断されたetcdノードに多数のリクエストが送信されないようにしました。

Kubenews #32

2021-09-24

How to deploy a comprehensive DevSecOps solution (click here to source)

RedHat®DevSecOpsフレームワークは、包括的な多層防御セキュリティ戦略の一環として、DevOpsライフサイクル全体の主要なセキュリティ要件に対応します。

Red HatのDevSecOpsフレームワークは、アプリケーションのライフサイクル全体に対応する9つのセキュリティカテゴリと32のメソッドとテクノロジーを識別します。

今回はその中のSecurityカテゴリーに関して書かれている。

Platform security

  • Host security
    • SELinuxによるaccess controls
    • Seccomp (secure computing mode)を用いたsystem callsを制御するためのkernel facilities
    • cgroupによるCPU, memoryやそのたリソースの隔離.
  • Container platform security
    • lightweight container runtime with CRI-O
    • a secure container image registry with Quay.
  • Linux namespaces
    • teams, groups, and departments間でのapplicationの隔離
  • Kubernetes and container hardening
    • NIST 800-190 and CIS Benchmarks.

Vulnerability and configuration management

脆弱性および構成管理機能は、アプリケーション、構成、およびコンテナーイメージのセキュリティ上の欠陥を改善、識別、分類、および解決するのに役立ちます。

  • Static application security testing (SAST)
    • 脆弱性や質の問題に対するコードの解析
  • Software composition analysis (SCA)
    • 既知の脆弱性やlicensing issueを特定するための依存パッケージ試験
  • Interactive application security testing (IAST) and dynamic application security testing (DAST)
    • 稼働中のアプリケーションの脆弱性チェック
  • Configuration management
    • 以下の点のようなGitOpsプロセスで構成を適切に管理することは、セキュリティを強化できます。
      • 変更管理の改善
      • 攻撃対象領域を減らす可能性のある構成上の欠陥の特定
      • 説明責任と改善の機会を高めるための署名や作成者の追跡
  • Image risk
    • コンテナイメージに関連するリスク
      • 脆弱な依存関係
      • 埋め込みのSecret
      • よろしくない構成
      • マルウェア
      • 信頼できないImage

Identity and access management

IDおよびアクセス管理(IAM)メソッドは、ユーザーまたはアプリケーションのIDと管理上定義されたポリシーに基づいて、オンプレミスおよびクラウドの資産、アプリケーション、およびデータへのアクセスを制御します。

  • 認証
  • 認可
  • Identity providers, secrets vaults, and hardware security modules (HSMs)
    • セキュリティクレデンシャル、キー、証明書、およびシークレットを管理および保護できます
  • Provenance
    • デジタル署名または証明記録を通じて、コードまたはImageの身元または信頼性を検証する機能。

Compliance

業界や政府の規制や企業ポリシーを順守するのに役立ちます。

上記のものは、以下のようなものに対するコンプライアンスを向上するのに役立ちます。

  • Payment Card Industry Data Security Standard (PCI-DSS)
  • ISO 27001 information security management standard
  • U.S. Health Insurance Portability and Accountability Act (HIPAA)
  • EU General Data Protection Regulation (GDPR)

Network controls

ネットワーク制御とセグメンテーション方法を使用すると、Kubernetesトラフィックを制御、分離、視覚化できます。

  • Kubernetes network security policies
  • Software-defined networking (SDN)
  • A hardened service mesh
  • Packet analysis
  • API management

Data controls

データ制御の方法とテクノロジーは、データの整合性を保護し、不正なデータ開示を防ぐのに役立ちます。

  • Data encryption
  • Data protection

Runtime analysis

プロダクションランタイムメソッドは、疑わしいアクティビティや悪意のあるアクティビティをリアルタイムで識別して軽減することにより、クラスターの衛生状態を維持するのに役立ちます。

  • Admission controlle
    • クラスターでの実行が許可されているものを管理および実施します。
  • Runtime application behavioral analysis
    • クラスターでの実行が許可されているものを管理および実施します。
  • Threat defense and runtime application self protection (RASP)

Audit and monitoring

監査および監視方法は、実稼働環境でのセキュリティインシデントに関する情報を提供します。 これらのメソッドは、イベントがいつ発生したかを記述し、考えられる原因と影響の情報を提供して、可視性を向上させ、インシデント対応を加速するのに役立ちます。

  • Monitoring
  • Security information and event management (SIEM)
    • 分散デバイス、エンドポイント、およびアプリケーションからのログとネットワークフローデータを統合することにより、イベントレポートを一元化します。
  • Forensics
    • セキュリティ違反への洞察を提供し、コンプライアンス監査をサポートする証拠を提供し、復旧作業を加速するための詳細なデータの収集を指します。

Remediation

本番環境でセキュリティインシデントが発生した場合、修復方法は自動的に修正措置を取ります。 これらは、稼働時間を改善し、データの損失を回避するのに役立ちます。

  • Security orchestration, automation, and response (SOAR)
  • Kubernetesの構成エラーとポリシー違反に関連する問題の自動解決。

Elasticsearchによる出前館店舗検索機能のパフォーマンス改善 (click here to source)

オンプレミス上のメインDB(Oracle)の高負荷問題がある一方、スケールアップもスケールアウトも難しい状況であったため、

データ参照用DB(PostgreSQL)をAWSに構築し、データ取得のみ行うAPI(参照系API)のDBアクセスを参照用DBに向ける、というプロジェクトが発足した際の話についてです。

本記事では、参照用DBへの移行後、店舗検索機能にElasticsearchを導入することで、パフォーマンス改善を行ったプロジェクトについて紹介されています。

vclusterにCustom Controller/Admission Webhookをデプロイしてみる(click here to source)

仮想クラスタにOperatorをデプロイする際の手順について書かれています。

NSA & CISA Kubernetes Security Guidance – A Critical Review (click here to source)

先日、米国の国家安全保障局NSA)と、サイバーセキュリティおよびインフラストラクチャセキュリティ庁(CISA)は、Kubernetesクラスターに適用することを推奨するセキュリティ強化の詳細を示すサイバーセキュリティテクニカルレポート(CTR)をリリースしました。

Kubernetes Hardening Guidance

この記事は、以下の三つに関して書かれている。

  1. Good
  2. Bad
    • NSA / CISAガイダンスがKubernetesセキュリティの重要な側面を見落としていた場所、またはガイダンスが公開された時点で古くなっていた場所。
  3. Complex
    • CTRガイダンスでカバーされていない、より一般的な複雑なユースケースのいくつかに関する考慮事項。
    • これには、過度なレベルの計算能力やストレージを必要としない有用な監査構成、外部依存関係の処理、Kubernetes RBACの複雑なメカニズムに関する注意事項が含まれます。

Good

  • Container Imagesのスキャン
  • 最小な権限の原則に従う
  • ネットワークの分離
  • ロギング構成
  • 定期的な構成レビュー

Bad

  • PSPの廃止
  • アドミッションコントローラー
  • 矛盾/誤った情報
    • ガイダンスの4ページには、KubeletとSchedulerの両方がデフォルトでTCP10251で実行されると記載されています。実際には、Kubeletのデフォルトポートは、読み取り/書き込みポートの場合はTCPポート10250であり、間もなく廃止される読み取り専用ポートの場合は10255です。
  • 認証の問題

Complex

  • 監査データのレベル
  • サイドカーのリソース要件
  • 外部依存関係は不可欠であること。
  • RBACは難しい
  • すべてにパッチを当てるのは難しい

DataRoaster is now open-sourced, why I created it (click here to source)

DataRoaster github

DataRoasterは、kubernetesで実行されるデータプラットフォームを提供するツールです。

DataRoasterが提供するデータプラットフォームには以下のようないくつかのコンポーネントがあります。

  • Hive MetaStore
  • Spark Thrift Server
    • JDBCODBCインターフェイスを使用してSparkに接続するためのもの。
      • ODBC: RDBMSにアクセスするための共通インタフェース (API)
      • JDBC: Java とリレーショナルデータベースの接続のためのAPI
    • Beeline や Tableau などの外部のクライアントから Spark に接続する際に使われます。
  • trino (github)
    • 高速な分散SQLクエリエンジン
  • redash
  • jupyterhub
    • ブラウザからアクセス/実行できるユーザ認証機能つきJupyterサーバー
  • kafka

DataRoasterデモ

www.youtube.com

7 Microservices Best Practices for Developers (click here to source)

マイクロサービスのメリットと課題

  • メリット

    • デプロイとスケーリングの高速化
      • アプリケーションドメインの責任が小さいほど自動化が可能になり、展開とスケーリングが高速化されます。
    • ダウンタイムの削減
      • 1つの利用できないサービスが主要なビジネス機能に与える影響を制限し、ビジネス全体の稼働時間を改善できる。
    • 可用性の確保
  • 課題

    • サービス間通信
      • モノリスアーキテクチャからマイクロサービスアプリケーションに関数を抽出すると、かつては内部関数呼び出しであったものが、その外部マイクロサービスの認証と承認を必要とする外部API呼び出しになります。
    • セキュリティレイヤー
      • モノリスアプリケーションでの認証と承認は、エントリの時点で1回処理できます。
      • マイクロサービスへの移行に伴い、すべてのマイクロサービスは、アクセス制御を実施するために何らかの認証と承認を実行する必要があります。
    • スケーラビリティ
      • マイクロサービスを使用すると、独立した機能をすばやく拡張できますが、これを効果的に行うには、優れたアプリ管理とさらに優れたツールが必要です。

マイクロサービスのベストプラクティス

1.小さなアプリケーションドメイン

マイクロサービス戦略を採用するには、単一責任の原則を採用する必要があります。

単一のサービスに対する責任の範囲を制限することにより、そのサービスの失敗による悪影響を制限します。

2.データストレージの分離

同じデータベースに接続する複数のマイクロサービスは、本質的には依然としてモノリシックアーキテクチャです。

モノリスは、アプリケーション層ではなくデータベース層にあるため、同じように壊れやすくなっています。各マイクロサービスには、可能な限り、独自のデータ永続化レイヤーが必要です。

これにより、他のマイクロサービスからの分離が保証されるだけでなく、特定のデータセットが使用できなくなった場合の爆風半径が最小限に抑えられます。

ファイルストアについても同様のケースを作成できます。

マイクロサービスアーキテクチャを採用する場合、同じファイルストレージサービスを使用するために個別のマイクロサービスを用意する必要はありません。

ファイルの実際の重なりがない限り、個別のマイクロサービスには個別のファイルストアが必要です。

3.通信チャネル

マイクロサービスが相互に通信する方法、特に関心のあるイベントに関しては、慎重に検討する必要があります。

そうしないと、単一の利用できないサービスが通信障害につながり、アプリケーション全体が崩壊する可能性があります。

マイクロサービス間の通信には、同期と非同期の2種類があります。

マイクロサービス間の同期通信では、チェーン内のリンクが切断されると機能しなくなってしまう依存関係チェーンが作成される可能性があります。

一方非同期通信では、サービスは要求を送信し、応答を待たずにその存続期間を継続します。

非同期通信への単純ですが効果的なアプローチは、パブリッシュ/サブスクライブパターンを採用することです。

対象のイベントが発生すると、プロデューサー(この場合はマイクロサービス)はそのイベントのレコードをメッセージキューサービスに公開します。

そのタイプのイベントに関心のある他のマイクロサービスは、そのイベントのコンシューマーとしてメッセージキューサービスにサブスクライブします。

4.互換性

可能な限り、下位互換性を維持して、コンシューマーが壊れたAPIに遭遇しないようにします。

一般的な方法は、/api/v1または/api/v2のようなパスレベルの互換性保証に従うことです。

後方互換性のない変更は、/api/v3のような新しいパスに移動します。

5.マイクロサービスのオーケストレーション

マイクロサービスのオーケストレーションは、プロセスとツールの両方で成功するための重要な要素です。

技術的には、systemdやDocker、podmanなどを使用して仮想マシンでコンテナーを実行できますが、コンテナーオーケストレーションプラットフォームと同じレベルの復元力は提供されません。

効果的なマイクロサービスオーケストレーションのために、バトルテスト済みのコンテナオーケストレーションプラットフォームに依存することをお勧めします。その分野の明確なリーダーはKubernetesです。

6.マイクロサービスのセキュリティ

セキュリティポリシーを適用するための一元化されたシステムは、悪意のあるユーザー、侵入型ボット、および欠陥のあるコードからアプリケーション全体を保護するために不可欠です。

7.メトリクスとモニタリング

(省略)

Kubenews #31

2021-09-17

Kubernetes CI/CD pipelines: What, why, and how (click here to source)

このブログの対象読者

  • エンタープライズソフトウェアとの旅の始まりにいる開発者
  • 会社のアプリケーションに取り組んでいる経験豊富なソフトウェアエンジニア
  • チームの生産性を向上させようとしているエンジニアリングリード

CI / CDパイプラインとは何

CI / CDパイプラインは、コード開発から本番展開まで、ソフトウェアが通過する一連の段階と自動化されたステップです。

CIは「継続的インテグレーション」の略で、ソフトウェアビルドパイプラインを指します。

CIには、開発者がコードを記述してからチームテスト段階にプッシュするまでのすべての手順が含まれています。

CDはソフトウェアリリースパイプラインを指し、「継続的デリバリー」または「継続的展開」のいずれかを表すことができます。

CDとは、一連の環境にコードをデプロイすることにより、コードが目的の機能を提供することを検証することであり、ソフトウェアを実際に本番環境に展開する前に、ソフトウェアが最終的に実行される実際の本番環境を複製することを目的としています。

Kubernetes CI / CDのメリットは何?

CI / CDワークフローとクラウドネイティブシステムには、いくつかの共通の目標があります。

どちらも、開発速度の向上、ソフトウェア品質の最適化、および操作性の維持を試みます。

CI / CDは、コードが開発されてから本番環境にリリースされるまでの多くのステップを自動化し、Kubernetesは、さまざまなインフラストラクチャ環境でのコンテナのデプロイを自動化し、効率的なリソースの利用を保証します。

組み込みのコンテナレジストリが付属しており、次の3つの方法でKubernetesと統合できます。

How Docker broke in half (click here to source)

1. Dockerが誕生

「パリのSolomonHykesによって2008年にDotCloudとして設立されたDockerとなる会社は、当初、開発者がアプリケーションを簡単に構築して出荷するためのサービスとしてのプラットフォーム(PaaS)として設計されました。」

という始まりから、Dockerの初期について書かれています。

2. オープンソースの商業化は難しい

当時どういう考えを持っていたのかや、実際に商用製品を出してみての結果について書かれています。

3. Kubernetesの決定

DockerとKubernetesの立ち位置や、DockerとKubernetesのコラボレーションはうまくいかなかった話について書かれています。

4. 上部の緊張

以下の2つのDockerが生まれる話などがされています。

  • DockerCommunityEditionは、開発者向けの非常に人気のあるコマンドラインツールおよびオープンソースプロジェクト
  • Docker Enterprise Editionは、大規模なコンテナーを採用したい企業顧客向けの一連の商用ツール

5. Dockerが2つに分かれる

Dockerは2019年11月にビジネスのエンタープライズ部分をMirantisに売却し、DockerEnterpriseはMirantisKubernetesEngineに吸収された話が書かれています。

6. 今日のDockerはどこにある?

  • 先週、DockerはDockerソフトウェアのライセンス条項の変更を発表したよ
  • 新しい開発者ツール, 安全で検証済みのimageといった信頼できるコンテンツの構築などに「Docker2.0」の成長の機会を見出している。

など、今後の展望や考えについて書かれている。

Integrating Keycloak and Open Policy Agent (OPA) with Confluent (click here to source)

OAuth2認証にKeycloakを使用し、ConfluentKafka内のトピックレベルの承認にOpenPolicy Agent(OPA)を使用する方法について書かれています。

Kubenews #30

2021-09-10

Managing Kubernetes seccomp profiles with security profiles operator (click here to source)

seccompプロファイルの作成と管理は煩雑であり、エラーが発生しやすくなるのを緩和する目的で作成された。

セキュリティプロファイルオペレータの機能

  • SeccompプロファイルCRD
  • seccompプロファイルをポッドにバインドするためのCRD
  • 実行中のポッドからseccompプロファイルを作成するためのCRD
  • Seccompプロファイルの同期とノードサポートの検証
  • メトリックス
  • ログエンリッチャー

インストール

cert-managerをインストールする必要があります。

$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.4.2/cert-manager.yaml

次にservice profile operatorのインストール

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/security-profiles-operator/master/deploy/operator.yaml

seccomp profileの作成

以下のプロファイルは、SCMP_ACT_LOGのデフォルトアクションのみを設定します。

profile1.yaml という名前でファイルを作成します。

apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: SeccompProfile
metadata:
  namespace: default
  name: profile1
spec:
  defaultAction: SCMP_ACT_LOG

では、作成していきます。

$ kubectl apply -f profile1.yaml
seccompprofile.security-profiles-operator.x-k8s.io/profile1 created

$ kubectl get seccompprofile profile1 --output wide
NAME       STATUS      AGE     LOCALHOSTPROFILE
profile1   Installed   7m21s   operator/default/profile1.json

作成されたプロファイルは、

/var/lib/kubelet/seccomp/operator/<namespace>/<profile name>.json

に格納されます。

$ ssh k8s-pool1-18290975-vmss000000 sudo cat /var/lib/kubelet/seccomp/operator/default/profile1.json
{"defaultAction":"SCMP_ACT_LOG"}

seccomp profileの利用

作成したprofileをPodに適用してきます。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: operator/default/profile1.json
  containers:
    - name: nginx
      image: nginx

プロファイルの継承

1つのprofileをベースとして使用して新しいカスタムプロファイルを作成することもできます。

apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: SeccompProfile
metadata:
  namespace: default
  name: inheritance-profile1
spec:
  defaultAction: SCMP_ACT_ERRNO
  baseProfileName: base-profile1
  syscalls:
    - action: SCMP_ACT_ALLOW
      names:
        - mkdir

profile bindings

PodのSpecを直接いじりたくない場合に、ProfileBindingが有用である。 今回は、nginx:1.21.1のimageを使用するPodに対して、最初に作成した profile1を適用させる例を紹介します。

apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: ProfileBinding
metadata:
  name: nginx-binding
spec:
  profileRef:
    kind: SeccompProfile
    name: profile1
  image: nginx:1.21.1

適用します。

$ kubectl apply -f nginx-binding.yaml
profilebinding.security-profiles-operator.x-k8s.io/nginx-binding created

以下のprofileを指定していないPodを作成すると挙動が確認できます。

$ cat <<EOF kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.21.1
EOF
pod/nginx created

$ kubectl get pod nginx -o jsonpath='{.spec.containers[*].securityContext.seccompProfile}'
{"localhostProfile":"operator/default/profile1.json","type":"Localhost"}

profileの記録

以下のmanifestを適用した場合、app: nginx というラベルを持ったPodが作成された際に記録が開始されます。 そして、そのポッドが削除されると、seccompプロファイルリソース(ポッドごと)が作成され、使用できるようになります。

apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: ProfileRecording
metadata:
  name: recording
spec:
  kind: SeccompProfile
  recorder: hook
  podSelector:
    matchLabels:
      app: nginx

Shipwright - Building Container Images In Kubernetes (click here to source)

Shipwrightとという、Kubernetes上でコンテナイメージを作成するツールが紹介されています。

リソースとしては、

  • BuildStrategy or ClusterBuildStrategy
  • Build
  • BuildRun

BuildStrategy or ClusterBuildStrategy

BuildのManifestで指定する、コンテナイメージをビルドする際に使用するツールについてです。

現在は、以下の選択肢があるみたいです。

  • Available ClusterBuildStrategies
Name Supported platforms
buildah linux/amd64 only
BuildKit all
buildpacks-v3-heroku linux/amd64 only
buildpacks-v3 linux/amd64 only
kaniko all
ko all
source-to-image linux/amd64 only
  • Available BuildStrategies
Name Supported platforms
buildpacks-v3-heroku linux/amd64 only
buildpacks-v3 linux/amd64 only

Build

ここで、実際にどうビルドするのかを定義します。

  • spec.source.url : アプリケーションのソースコードのあるレポジトリを指定
  • spec.strategy : ビルドツールを指定
  • spec.output : 作成したimageをプッシュするregistryを指定
    • output.credentials.name : registryにアクセスする際に使用する既存のsecretを指定
apiVersion: shipwright.io/v1alpha1
kind: Build
metadata:
  name: s2i-nodejs-build
spec:
  source:
    url: https://github.com/shipwright-io/sample-nodejs
  strategy:
    name: kaniko
    kind: ClusterBuildStrategy
  output:
    image: us.icr.io/source-to-image-build/nodejs-ex
    credentials:
      name: icr-knbuild

例えば、

  • レポジトリのrootディレクトリにソースコードがない場合は、spec.source.contextDirにて指定
  • 独自のビルドツールを積んでいるimageを使う場合、spec.strategy.namesource-to-imageにし、spec.builder.imageにてそのimageを指定する

など、柔軟性がありそう。

apiVersion: shipwright.io/v1alpha1
kind: Build
metadata:
  name: s2i-nodejs-build
spec:
  source:
    url: https://github.com/shipwright-io/sample-nodejs
    contextDir: source-build/
  strategy:
    name: source-to-image
    kind: ClusterBuildStrategy
  builder:
    image: docker.io/centos/nodejs-10-centos7
  output:
    image: us.icr.io/source-to-image-build/nodejs-ex
    credentials:
      name: icr-knbuild

BuildRun

Kubernetes上でBuildを実行するリソース。

apiVersion: shipwright.io/v1alpha1
kind: BuildRun
metadata:
  name: buildpack-nodejs-buildrun-namespaced
spec:
  buildRef:
    name: s2i-nodejs-build
  serviceAccount:
    name: pipeline

Buildで定義したプッシュ先を上書きしたい場合、このリソースでも定義ができる。

apiVersion: shipwright.io/v1alpha1
kind: BuildRun
metadata:
  name: buildpack-nodejs-buildrun-namespaced
spec:
  buildRef:
    name: s2i-nodejs-build
  serviceAccount:
    name: pipeline
  output:
    image: us.icr.io/source-to-image-build/nodejs-ex
    credentials:
      name: icr-knbuild

Distributed tracing with Knative, OpenTelemetry and Jaeger (click here to source)

Knative、OpenTelemetry、Jaegerを使った分散トレーシングについて書かれています。

Setup

既にKnative Serving and Eventingがデプロイされてていることを前提としています。

まず、クラスターにOpenTelemetryオペレーターを追加します。 こちらは、cert-managerに依存しているため、そちらもデプロイします。

$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/latest/download/cert-manager.yaml 

$ kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

次に、イェーガーオペレーターをデプロイします。

$ kubectl create namespace observability
$ kubectl create -n observability \
    -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/master/deploy/crds/jaegertracing.io_jaegers_crd.yaml \
    -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/master/deploy/service_account.yaml \
    -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/master/deploy/role.yaml \
    -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/master/deploy/role_binding.yaml \
    -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/master/deploy/operator.yaml

起動したら、次のコマンドを実行してJaegerインスタンスを作成できます。

$ kubectl apply -n observability -f - <<EOF
apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simplest
EOF

次に、OpenTelemetryコレクターを作成します。

$ kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: otel
  namespace: observability
spec:
  config: |
    receivers:
      zipkin:
    exporters:
      logging:
      jaeger:
        endpoint: "simplest-collector.observability:14250"
        insecure: true

    service:
      pipelines:
        traces:
          receivers: [zipkin]
          processors: []
          exporters: [logging, jaeger]
EOF

最後に、すべてのトレースがコレクターを指すようにEventing andServingを構成します。

$ for ns in knative-eventing knative-serving; do
  kubectl patch --namespace "$ns" configmap/config-tracing \
   --type merge \
   --patch '{"data":{"backend":"zipkin","zipkin-endpoint":"http://otel-collector.observability:9411/api/v2/spans", "debug": "true"}}'
done

Hello World

トレースインフラストラクチャがすべてデプロイおよび構成されたので、ハートビートイメージ をContainerSourceとして デプロイして、 すべてが正しく接続されていることをテストおよび確認できます。

$ kubectl apply -f - <<EOF
apiVersion: sources.knative.dev/v1
kind: ContainerSource
metadata:
  name: heartbeats
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-nightly/knative.dev/eventing/cmd/heartbeats:latest
          name: heartbeats
          args:
            - --period=1
          env:
            - name: POD_NAME
              value: "heartbeats"
            - name: POD_NAMESPACE
              value: "default"
            - name: K_CONFIG_TRACING
              value: '{"backend":"zipkin","debug":"true","sample-rate":"1","zipkin-endpoint":"http://otel-collector.observability:9411/api/v2/spans"}'
  sink:
    uri: http://dev.null
EOF

今のところ、このコンテナは存在しないドメインhttp://dev.nullにハートビートを送信しているだけなので、このポッドのログを見ると、一連のDNS解決エラーが表示されますが、otel-collectorポッドのログを調べると、サービスからトレースを正常に受信していることがわかります。

ハートビートを受信するためにKnativeサービスを追加し、ハートビートサービスを更新します。

$ kubectl apply -f - <<EOF
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: event-display
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-nightly/knative.dev/eventing/cmd/event_display:latest
          env:
            - name: K_CONFIG_TRACING
              value: '{"backend":"zipkin","debug":"true","zipkin-endpoint":"http://otel-collector.observability:9411/api/v2/spans"}'
EOF

$ kubectl apply -f - <<EOF
apiVersion: sources.knative.dev/v1
kind: ContainerSource
metadata:
  name: heartbeats
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-nightly/knative.dev/eventing/cmd/heartbeats:latest
          name: heartbeats
          args:
            - --period=1
          env:
            - name: POD_NAME
              value: "heartbeats"
            - name: POD_NAMESPACE
              value: "default"
            - name: K_CONFIG_TRACING
              value: '{"backend":"zipkin","debug":"true","zipkin-endpoint":"http://otel-collector.observability:9411/api/v2/spans"}'
  sink:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: event-display
EOF

これらのサービスがデプロイされたら、Jaegerダッシュボードでもう一度確認することで、おもしろいとレースが表示されます。

Getting fancy

Hello Worldより複雑な構成を紹介してくれているので、記事を読んでみてください。

Kubenews #extra-001

2021-09-**

配信なし

monday.com’s Multi-Regional Architecture: A Deep Dive (click here to source)

マルチリージョンに移行することを決定するときは、パフォーマンス優先、復元力優先、プライバシー優先等の優先事項に対する設計間で作業が大きく異なるため、主な動機を理解する必要があります。

プラットフォームを複数の地域で実行するに至る3つの主な動機

  • パフォーマンス

    • サーバーを顧客の近くで実行すると、待ち時間が短くなり、接続品質が向上し(特にモバイルで)、一般的にエンドユーザーのエクスペリエンスが向上します。
  • レジリエンス

    • 任意のリージョンにおいて任意の時点でユーザーにサービスを提供できる場合、複数のリージョンでシステムを同時に実行することは、システムの全体的なフォールトトレランスの向上、ダウンタイムの短縮につながる。
  • プライバシーとコンプライアンス

    • 顧客が世界のどこにデータを保存するかを選択できるようにすることで、明確な競争上の優位性が生まれ、PIIや機密情報を処理するヘルスケア、銀行、企業などの厳しく規制された業界との連携への扉が開かれます。

2番目のリージョンを追加する際の課題

【課題1】 サブドメインは基本的にスラッグであるが、完全ではない。

ユニークなサブドメインを使えるものもあれば、すべての顧客が使用する共有サブドメインがも存在してしまう。

【課題2】ユーザーが誰であるかさえわからない場合がある。

ログインフローにおいて、匿名の訪問者がプラットフォームに到着し、電子メールとパスワードを入力して、最終的にアカウントにルーティングされる際に、すべてのユーザーが同じサブドメインにアクセスします。

この時、どのリージョンがログインフローを処理するのか。

【課題3】可能な限りベンダーに中立を保つ

アーキテクチャを単一のネットワークサービスプロバイダーにチェーンした場合、いざ大規模な停止が起こった際に、インフラストラクチャ全体を再構築せずに回復することが難しい。

【課題4】再現性

簡単に複製できる方法で新しいリージョンを構築したかった。

monday.comのマルチリージョンデザイン

設計の重要なポイントとして以下を上げている。

  • 各リージョンの独立
  • ユーザーは各リージョンに直接アクセス可能
  • 認証はグローバル
  • ベンダー中立性

そのほか、処理の流れの説明が書かれています。

マルチリージョンをサポートするためのアンバサダーの構成

前で説明したことを基に、マルチリージョンネットワーク、認証サービス、API構造を結び付ける構成について、深く掘り下げて説明がされています。

マルチリージョンでのアプリケーションの展開

次の3つのデプロイトポロジをサポートしているようです。

  • Regional

    • 地域ごとに分けて展開されるアプリケーションは、独立したコンポーネントとしてあらゆるリージョンに展開されます。

    • 各デプロイメントは、地域ごとに独立していて、データを共有せず、互いを認識しないようになっています。

  • Global

    • グローバルなアプリケーションは米国で一度展開され、すべての地域から内部ネットワークを介してアクセスできるようになっている。
  • Replicated

    • レプリケートされたアプリケーションはすべてのリージョンに独立してデプロイされますが、データベースに関しては単一のレプリケートされたものを共有し、それらの状態はすべてのリージョンで同じものになっている。

ロギングとモニタリング

  • Envoy アクセスログ

    • すべてのリージョンからのすべてのアクセスログを一元化されたログシステムにストリーミングします。
  • Prometheus / Grafana

  • AWS CloudWatch

    • インフラストラクチャ全体がAWSクラウド上に構築されているため、トランジットゲートウェイVPC、NLBメトリックを使用して、内部ネットワークアクティビティを追跡します。

Kubernetes Supply Chain Policy Management with Cosign and Kyverno (click here to source)

以前は、connaseiurというツールを紹介しました。

ryo-xjsbx.hatenablog.com

今回はみんな大好きkyverno!

Image Signing with Cosign

  • cosign (github)

  • Generate a keypair

$ cosign generate-key-pair
Enter password for private key:
Enter again:
Private key written to cosign.key
Public key written to cosign.pub
  • Sign a container and store the signature in the registry
$ cosign sign -key cosign.key dlorenc/demo
Enter password for private key:
Pushing signature to: index.docker.io/dlorenc/demo:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8.sig
  • Verify a container against a public key
$ cosign verify -key cosign.pub dlorenc/demo
The following checks were performed on these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"sha256:87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8"},"Type":"cosign container image signature"},"Optional":null}

Cosign Image Signature Verification with Kyverno

「ghcr.io/kyverno/」リポジトリの「test-verify-image」という名前で始まるのすべてのイメージを対象として、cosignの共通鍵で複合化できるのかを確認してくれる。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-image
spec:
  validationFailureAction: enforce
  background: false
  rules:
    - name: check-image
      match:
        resources:
          kinds:
            - Pod
      verifyImages:
      - image: "ghcr.io/kyverno/test-verify-image:*"
        key: |-
          – ---BEGIN PUBLIC KEY-----
          MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8nXRh950IZbRj8Ra/N9sbqOPZrfM
          5/KAQN0/KjHcorm/J5yctVd7iEcnessRQjU917hmKO6JWVGHpDguIyakZA==
          – ---END PUBLIC KEY--- –  

署名されたimageを使ってdeployすると通ります。

kubectl create deployment signed \
--image=ghcr.io/kyverno/test-verify-image:signed

署名されてないimageを使った場合、kyvernoによって弾かれる。

kubectl create deployment unsigned \
--image=ghcr.io/kyverno/test-verify-image:unsigned

error: failed to create deployment: admission webhook "mutate.kyverno.svc" denied the request:

resource Deployment/default/unsigned was blocked due to the following policies

verify-image:
  autogen-verify-image: 'image verification failed for ghcr.io/kyverno/test-verify-image:unsigned:
    signature not found'

別のキーペアにおける鍵で署名されたimageも通りません。

kubectl create deployment signed-other \
--image=ghcr.io/kyverno/test-verify-image:signed-by-someone-else

error: failed to create deployment: admission webhook "mutate.kyverno.svc" denied the request:

resource Deployment/default/signed-other was blocked due to the following policies

verify-image:
  autogen-verify-image: 'image verification failed for ghcr.io/kyverno/test-verify-image:signed-by-someone-else:
    invalid signature'

Audit Logging in Clusters (click here to source)

Falcoを使用した監査ログの検索について書かれています。

監査ポリシー

監査ポリシーは、監査ログの構成を定義します。どのイベントが監査の対象に入るのかを制御します。

パラメータ「omitStages」を使用して、リクエストがログに記録されないようにする対象を定義できます。

監査ポリシーのYAMLファイル

apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
  - "RequestReceived"
rules:
  # Log pod changes at RequestResponse level
  - level: RequestResponse
    resources:
    - group: ""
      # Resource "pods" doesn't match requests to any subresource of pods,
      # which is consistent with the RBAC policy.
      resources: ["pods"]
  # Log "pods/log", "pods/status" at Metadata level
  - level: Metadata
    resources:
    - group: ""
      resources: ["pods/log", "pods/status"]

  # Don't log requests to a configmap called "controller-leader"
  - level: None
    resources:
    - group: ""
      resources: ["configmaps"]
      resourceNames: ["controller-leader"]

リクエストのステージ

リクエストをログに記録できる4つの段階は、次のように定義されています。

  • RequestReceived

    • サーバーが応答の発行を開始する前の段階。
  • ResponseStarted

    • リクエストのヘッダーの作成は完了したが、レスポンスの本文は送信されていない段階。
  • ResponseComplete

    • リクエストに対するレスポンスボディが完了した段階。
  • Panic

    • パニックが発生した段階。

イベントのレベル

  • None

    • このルールに一致するイベントはログに記録されません。
  • Metadata

    • リクエストのメタデータのみをログに記録し、リクエストまたはレスポンスのbodyはログに記録しません。
  • Request

    • イベントのメタデータとリクエストbodyをログに記録しますが、レスポンスbodyはログに記録しません。
  • RequestResponse

    • イベントメタデータ、リクエストおよびレスポンスのbodyをログに記録します。
    • これは最も有益なレベルですが、クラスターに高い負荷をかける可能性があります

パラメータ「rules」は、監査ポリシーYAMLファイルで必要な唯一のパラメータです。

ここで、どのリクエストをどのレベルでログに記録するかを定義できます。

たとえば、先ほどの例の最初のruleは、Podのすべての変更がRequestResponseレベルでログに記録されることを示しています。

監査のバックエンド

監査ログを外部ストレージに書き込むことに関して、2つの方法があります。

  • ログバックエンド

  • webhookバックエンド

    • イベントを外部HTTPAPIに送信します

kubescape (click here to source)

Kubernetes Hardening Guidance by NSA and CISAに基づいて、Cluster内のリソースをチェックしてくれます。

$ kubescape scan framework nsa --exclude-namespaces kube-system,kube-public
ARMO security scanner starting
[progress] Downloading framework definitions
[success] Downloaded framework
[progress] Accessing Kubernetes objects
W0831 18:12:29.875935     241 warnings.go:70] batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob
[success] Accessed successfully to Kubernetes objects, let’s start!!!
[progress] Scanning cluster
◑ [success] Done scanning cluster
[control: Allow privilege escalation] passed 👍
Description: Attackers may gain access to a container and uplift its privilege to enable excessive capabilities.
Summary - Passed:1   Failed:0   Total:1

・・・

[control: Control plane hardening] passed 👍
Description: Kubernetes control plane API is running with non-secure port enabled which allows attackers to gain unprotected access to the cluster.
Summary - Passed:1   Failed:0   Total:1

[control: Dangerous capabilities] passed 👍
Description: Giving dangerous and unnecessary capabilities for a container can increase the impact of a container compromise.
Summary - Passed:1   Failed:0   Total:1

・・・

[control: Privileged container] failed 😥
Description: Potential attackers may gain access to privileged containers and inherit access to the host resources. Therefore, it is not recommended to deploy privileged containers unless it is absolutely necessary.
   Namespace kube-image
      DaemonSet - builder
Summary - Passed:0   Failed:1   Total:1
Remediation: Change the deployment and/or pod definition to unprivileged. The securityContext.privileged should be false.

・・・

+-------------------------------------------------+------------------+---------------+-----------+
|                  CONTROL NAME                   | FAILED RESOURCES | ALL RESOURCES | % SUCCESS |
+-------------------------------------------------+------------------+---------------+-----------+
| Allow privilege escalation                      | 0                | 1             | 100%      |
| Allowed hostPath                                | 1                | 1             | 0%        |
| Anonymous requests                              | 0                | 0             | NaN       |
| Applications credentials in configuration files | 3                | 4             | 25%       |
| Automatic mapping of service account            | 3                | 3             | 0%        |
| Cluster-admin binding                           | 4                | 122           | 96%       |
| Container hostPort                              | 1                | 1             | 0%        |
| Control plane hardening                         | 0                | 1             | 100%      |
| Dangerous capabilities                          | 0                | 1             | 100%      |
| Exec into container                             | 4                | 122           | 96%       |
| Exposed dashboard                               | 0                | 2             | 100%      |
| Host PID/IPC privileges                         | 1                | 1             | 0%        |
| Immutable container filesystem                  | 1                | 1             | 0%        |
| Ingress and Egress blocked                      | 1                | 1             | 0%        |
| Insecure capabilities                           | 0                | 1             | 100%      |
| Linux hardening                                 | 1                | 1             | 0%        |
| Non-root containers                             | 0                | 1             | 100%      |
| Privileged container                            | 1                | 1             | 0%        |
| Resource policies                               | 1                | 1             | 0%        |
| hostNetwork access                              | 1                | 1             | 0%        |
+-------------------------------------------------+------------------+---------------+-----------+
|                       20                        |        23        |      267      |    91%    |
+-------------------------------------------------+------------------+---------------+-----------+

Writing a Kubernetes Validating Webhook using Python (click here to source)

Validating Webhookを実行するコンテナをPythonを用いて作成する方法について書かれています。

How to Secure Containers with Cosign and Distroless Images (click here to source)

Distroless Container Imagesとは何か。

Distroless Container Imagesは、「言語に焦点を合わせたDockerイメージからオペレーティングシステムを除いたもの」です。つまり、アプリケーションとそのランタイム依存関係のみが含まれ、他の通常のOSパッケージマネージャー、Linuxシェル、または標準のLinuxディストリビューションで通常期待されるようなプログラムは含まれません。

ソース

ディストロレスコンテナイメージと一緒にCosignが必要な理由

Cosignの必要性は、ディストロレスイメージを使用しても、タイポスクワッティング攻撃や悪意のあるイメージの受信などのセキュリティ上の脅威に直面する可能性があるためです。

Cosign検証を使用した、ディストロレスコンテナのベースイメージの検証。

こちらでは、実際にディストロレスコンテナイメージとcosignを使用したDemoを紹介してくれています。

Easy, Secure Kubernetes Authentication With Pinniped (click here to source)

Pinnipedについて、Demoを交えて説明してくれています。

Kubenews #29

2021-08-20

youtu.be

Encrypt your Kubernetes Secrets with Mozilla SOPS (click here to source)

Kubernetes Secretsは、base64で暗号化されていて、簡単に複合化できてしまう。 そのソリューションとして、Mozilla SOPSがある。

github : SOPS

・特徴

  • yaml, json, ini, binaryなどに対応

  • 以下のようなSolutionと連携が可能

    • PGP
    • Azure Key Vault
    • AWS KMS
    • GCP KMS
    • HashiCorp Vault

この記事では、Azureに関しての例が書かれており、Azure Service Principal (SP) を使うことを推奨しています。

  • Provision an Azure Service Principal (SP)
# create a service principal
az ad sp create-for-rbac -n sp-sops-keyvault -o json
# {
#   "appId": "00000000-0000-0000-000000000000",
#   "displayName": "http://sp-sops-keyvault",
#   "name": "http://sp-sops-keyvault",
#   "password": "00000000-0000-0000-000000000000",
#   "tenant": "<your_tenant_identifier>
# }

export AZURE_CLIENT_ID=<appId>
export AZURE_CLIENT_SECRET=<password>
export AZURE_TENANT_ID=<tenant>
  • Provisioning an Azure Key Vault instance
# create a new Resource Group
az group create -n rg-sops-sample -l germanywestcentral

# create a Key Vault instance
az keyvault create -n kv-sops-sample \
   -g rg-sops-sample \
   -l germanywestcentral 

# create an access policy for the SP
az keyvault set-policy -n kv-sops-sample \
   -g rg-sops-sample \
   --spn $AZURE_CLIENT_ID \
   --key-permissions encrypt decrypt
  • Create a key in Azure Key Vault for encryption & decryption
# create an key for encryption / decryption 
az keyvault key create -n sops-sample-key \
    --vault-name kv-sops-sample \
    --ops encrypt decrypt \
    --protection software

# read and store key identifier
export KEY_ID=$(az keyvault key show -n sops-sample-key \
    --vault-name kv-sops-sample \
    --query key.kid -o tsv)
# download sops cli for macOS
curl -O -L -C - https://github.com/mozilla/sops/releases/download/v3.7.1/sops-v3.7.1.darwin

# move and rename the cli to /usr/bin
sudo mv sops-v3.7.1.darwin /usr/bin/sops

# make it executable
sudo chmod +x /usr/bin/sops

まず、Sercretを作成します。

# create the Kubernetes secret
kubectl create secret generic demo \
    --from-literal mysecret=secret_value \
    -o yaml \
    --dry-run=client > secret.encoded.yml

# print the contents of secret.encoded.yml
cat secret.encoded.yml

# apiVersion: v1
# data:
#   mysecret: c2VjcmV0X3ZhbHVl
# kind: Secret
# metadata:
#   creationTimestamp: null
#   name: demo

sopsコマンドを用いて、暗号化します。

# encrypt secret.encoded.yml using SOPS
sops --encrypt --encrypted-regex '^(data|stringData)$' \
    --azure-kv $KEY_ID secret.encoded.yml > secret.encrypted.yml

# print the contents of secret.encrypted.yml
cat secret.encrypted.yml

# apiVersion: v1
# data:
#    mysecret: ENC[AES256_GCM,data:gz/WAjWte3bCnNm6e+G4ow==,iv:VB4pAv833tDdD4n76h4CqEZNpGdwA3V1QGWp7PK/Jfc=,tag:CcUy3rti4XcWArmHANVS8Q==,type:str]
# kind: Secret
# metadata:
#     creationTimestamp: null
#     name: demo
# sops:
#     kms: []
#     gcp_kms: []
#     azure_kv:
#         - vault_url: https://kv-sops-sample.vault.azure.net
#           name: sops-sample-key
#           version: ee44c0c0cc9e4620aa4f4c86c4942047
#           created_at: "2021-08-02T20:55:40Z"
#           enc: EjszDACgiDP8rW3wzs-7fAmFzlAhCq0-R9YlA9cuPcq78EXEeNTC8OnlSdXQAGdGrgE9oylu1HKZa4RB9GxzzVDav8uNVPp67NPmC4-teeA5iRE4jqlp1An6sG6CpkZGcAmKWpfj_DEWecqrNGWSLTA2hI_HKwG5xNkFh9Myik6732W-XL65IFqgepcFrNIzeHetznO0j1iISNXqMeJjeCnZ6Qq0jcXUMIfQnXjAllKfjSukiT3A3GlWxP0j50Z328t-JHi5RowYHT-hC8FDOdR_U95sqnFd27RgEXmbDIU6IGvP3vmCiZJz4YQCPXaGhySvFY6qCEoCbCSC4RaoWw
#     hc_vault: []
#     age: []
#     lastmodified: "2021-08-02T20:55:41Z"
#     mac: ENC[AES256_GCM,data:AmKRnzoImfIzPa3JBcuxUKRrse5uZwJGukpLj1wxed3R7lsUN+QAV1+WkfNyeMoW5C3ek7j20Xpbvzi+MgP8zcQOwWSwA79Svgz3hKMn9eTRTfgU+4jYezIIHCwkv61MTN8RGW5AhOInYP8oRPW3zKD+SbBO/Jeu7SC+/oVn07I=,iv:S4Th+0quL84lhJtA/lugEv+iLc+WhWEYPSlXGWKhd/M=,tag:CUGg8+UM7gNSzfjJx1Ua1w==,type:str]
#     pgp: []
#     encrypted_regex: ^(data|stringData)$
#     version: 3.7.1

# delete encoded version of the secret
rm secret.encoded.yml

# add encrypted secret to source control and commit it
git add secret.encrypted.yml
git commit -m 'chore: add encrypted secret'

sopsコマンドを用いて複合化ができます。

# decrypt and deploy the secret
sops --decrypt secret.encrypted.yml | kubectl apply -f -

いつものSecret同様、Pod等から参照が可能です。

apiVersion: v1
kind: Pod
metadata:
  name: echo
  labels:
    app: echo
spec:
    containers:
    - image: thorstenhans/env-via-http:0.0.1
      name: main
      ports:
        - containerPort: 5000
          protocol: TCP
      envFrom:
        - secretRef:
            name: demo
            optional: true
      resources:
        requests:
          cpu: 50m
          memory: 32Mi
        limits:
          cpu: 100m
          memory: 48Mi 

Implementing traffic policies in Kubernetes (click here to source)

Kumaを使用したKubernetesトラフィックポリシーの設計について

2つのバックエンドサービスは外部ネットワークから分離した状態で、ある1つのサービスからの通信を許可したい場合、以下のようなポリシーを適用できる。

cat <<EOF | kumactl apply -f - 
type: TrafficPermission
name: api-to-backends
mesh: default
sources:
  - match:
      service: 'publicAPI'
destinations:
  - match:
      service: 'backend1'
  - match:
      service: 'backend2'
EOF

How to Run HAProxy with Docker (click here to source)

Dockerの実行によるパフォーマンスへの影響

Dockerを使用すると、ホストへのブリッジネットワークを作成することで、コンテナー内で実行されているサービスにアクセスできます。

よって、コンテナのローカルネットワークとホストのブリッジネットワーク間でネットワークアドレス変換(NAT)をするため、遅延が発生します。

前に引用した同じIBMの調査では、DockerのNATによって、クライアントからの100バイトの要求とアプリケーションからの200バイトの応答のレイテンシーが約35 µsから70 µsに倍増されたらしい。

非常に低いレイテンシが必要な場合は、Dockerのホストネットワーク機能の使用に切り替えることで、コンテナはホストと同じネットワークを共有できるため、NATの必要性がなくなります。

Dockerを実行する際のセキュリティに関する考慮事項

HAProxyは、80や443などの制限されたTCPポートにバインドする必要があるため、rootアクセスが必要です。

ただし、起動が完了すると、root権限が削除され、非特権ユーザーとして実行されます。

DockerでHAProxyを実行する

3つのアプリケーションを動かします。

$ sudo docker network create --driver=bridge mynetwork

$ sudo docker run -d \
   --name web1 --net mynetwork jmalloc/echo-server:latest
   
$ sudo docker run -d \
   --name web2 --net mynetwork jmalloc/echo-server:latest
   
$ sudo docker run -d \
   --name web3 --net mynetwork jmalloc/echo-server:latest

$ sudo docker ps

CONTAINER ID   IMAGE                        COMMAND              CREATED              STATUS              PORTS      NAMES
98216bb8c5ff   jmalloc/echo-server:latest   "/bin/echo-server"   About a minute ago   Up About a minute   8080/tcp   web3
ae6accc111d9   jmalloc/echo-server:latest   "/bin/echo-server"   About a minute ago   Up About a minute   8080/tcp   web2
554fafbc2b3b   jmalloc/echo-server:latest   "/bin/echo-server"   About a minute ago   Up About a minute   8080/tcp   web1

HAProxyロードバランサーを介してこれらのコンテナーにトラフィックを中継できるよう、現在のディレクトリにhaproxy.cfgという名前のファイルを作成し、それに以下を追加します。

global
  stats socket /var/run/api.sock user haproxy group haproxy mode 660 level admin expose-fd listeners
  log stdout format raw local0 info

defaults
  mode http
  timeout client 10s
  timeout connect 5s
  timeout server 10s
  timeout http-request 10s
  log global

frontend stats
  bind *:8404
  stats enable
  stats uri /
  stats refresh 10s

frontend myfrontend
  bind :80
  default_backend webservers

backend webservers
  server s1 web1:8080 check
  server s2 web2:8080 check
  server s3 web3:8080 check
  • 最初のフロントエンドはポート8404でリッスンし、HAProxy Statsダッシュボードを有効にします。このダッシュボードには、ロードバランサーに関するライブ統計が表示されます。

  • もう一方のフロントエンドはポート80でリッスンし、Webサーバーのバックエンドにリストされている3つのWebアプリケーションの1つに要求をディスパッチします。

以下のコマンドで、HAProxyを作成します。

$ sudo docker run -d \
   --name haproxy \
   --net mynetwork \
   -v $(pwd):/usr/local/etc/haproxy:ro \
   -p 80:80 \
   -p 8404:8404 \
   haproxytech/haproxy-alpine:2.4

Kubernetes CI/CD with Tekton and ArgoCD (click here to source)

TektonとArgoCDを使用してKubernetesでCI / CDプロセスを構成する方法が書かれています。

AWS App MeshとIstioの比較 (click here to source)

AWSが提供するサービスメッシュのマネージドサービスであるApp MeshとIstioの比較について書かれています。

比較項目としてはいかがあります。

  • ECS環境での利用
  • トラフィックルーティング
  • 障害分離(タイムアウト、リトライ、サーキットブレーカー)
  • Ingress
  • セキュリティ機能
  • オブザーバビリティ関連の機能

OPA GatekeeperによるKubernetesセキュリティの歩き方 (click here to source)

以下のような、運用をしていく中でこういったことに注意したなどの事例を基に説明されている。

ConstraintとConstraintTemplateを何も考えずにクラスタに適用してしまうと、意図していないリソースまでも影響を受ける可能性があります。

enforcementAction: dryrunを使用し、一定期間様子を見ながら適用することをおすすめします