ry's Tech blog

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

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.メトリクスとモニタリング

(省略)