本記事では、AWSとRed Hatが共同提供するフルマネージドなOpenShiftサービス「ROSA」について紹介します。 特に、近年の主流であり、インフラ費用や運用負荷を劇的に削減できるROSAの最新アーキテクチャモデル「HCP（Hosted Control Planes）」の仕組みと、導入による4つのメリットを分かりやすく紹介し、最適なコンテナ基盤選定のヒントをお届けします。 ROSAとは ROSA（Red Hat OpenShift Service on AWS）とは、Red Hatが提供しているコンテナオーケストレーションプラットフォームであるOpenShiftを、AWS上のフルマネージドサービスとして利用できるようにしたサービスです。（ OpenShiftについて詳しく知りたい方は、 こちら の記事をご参考ください） ROSAを利用してコンテナ基盤を運用することには、以下の利点があります。 Red HatとAWSの共同サポート ROSAは、サポート窓口が完全に一元化されていて、問い合わせを受けると、裏側でAWSとRed Hatのエンジニアが直接連携して原因を突き止めてくれる仕組みになっています。自分たちでAWS上にOpenShiftを構築した場合、トラブルが起きると「AWSのインフラが悪いのか、それともOpenShiftのバグなのか」を自力で調べ、それぞれのサポートに別々に問い合わせなければなりません。ROSAであればそのようなアクションが一切不要になるため、運用の負担を大きく軽減できます。 Red Hatの専門チームによる24時間監視 ROSAのクラスターは、Red HatのSREチームによって24時間365日体制で監視・運用されるようになります。 クラスターに何か障害が起きても、Red HatのSREチームが裏側で迅速に対応・復旧をしてくれるため、ユーザーとしては、監視や障害対応に対する運用コストを飛躍的に削減できます。 また、パッチ当てやセキュリティのアップデートなどもRed Hat側が対応してくれるので、ユーザーはそのスケジュール（実行するタイミング）を決めるだけで済みます。 AWSサービスと連携しやすくなる ROSAは、最初からAWSの各種サービスとスムーズに連携できるよう設計されています。これによって、複雑なインフラ設定に時間を取られなくなるため、より迅速かつ安全にコンテナ基盤を構築・提供できるようになります。 Copyright © Red Hat, Inc. AWSのRoleとPolicyを利用したRed Hat側との連携 請求書の統合 ROSAの利用料金（OpenShiftのライセンス料やAWSのインフラ費用）は、すべてAWSの請求書に統合されて支払われます。 別個に契約や支払いを行う必要がないため、企業の購買手続きや予算管理の負担を大幅に軽減できるメリットがあります。   ROSAを使うことで、上記のように様々なメリットが得られますが、現在の標準アーキテクチャである「HCP（Hosted Control Planes）」の登場によって、更なるフルマネージドのサービスが利用可能になりました。 ここからは、コストや運用の楽さを劇的に向上させる「ROSA with HCP」について詳しく説明します。 ROSA with HCPとは ROSA with HCP ( Red Hat OpenShift Service on AWS with hosted control planes ) とは、簡単に言うとコントロールプレーンをRed Hat側のAWSに配置し、完全に管理を任せる仕組みです。 HCPが登場する前の従来の方式は、HCPと区別するために「ROSA Classic」と呼ばれていますが、以下の構成図を見ていただくと、一目でその違いが理解できると思います。 Copyright © Red Hat, Inc. ROSA Classicの構成図 Copyright © Red Hat, Inc. ROSA with HCPの構成図 構成図からもわかるように、Classic方式では、コントロールプレーンノードがユーザー自身のAWSアカウント（VPC）内に配置され、ワーカーノードと共存していました。 一方、HCP方式では、コントロールプレーンがユーザーのネットワーク環境から安全に分離された場所に配置され、AWS PrivateLinkを介してやり取りする仕組みになっています。 このような構成の違い以外にも、HCP方式は数多くのメリットを持っています。ここからは、どのようなメリットがあるか紹介します。 コントロールプレーンの管理コストの削減 コントロールプレーンには、APIサーバーやetcdデータベースなど、クラスター全体を制御する極めて重要なコンポーネントが含まれています。これらをRed Hat側が完全に管理・運用してくれるため、ユーザーの運用保守のコストが大幅に削減されます。 AWSインフラ費用（EC2代金）を節約できる 従来のClassic方式では、コントロールプレーンを構成するノード（EC2インスタンス）をユーザー自身のAWS環境内に作成する必要がありました。 OpenShiftの仕様上、クラスターの安定稼働（高可用性）を維持するためには最低3台のコントロールプレーンノードが必須となりますので、小規模な開発環境であっても、ベースとなるEC2の固定費用がどうしても高くなってしまうというコスト面の課題がありました。 HCP方式では、このコントロールプレーンがRed Hat側に完全に移動するので、ユーザーのAWSアカウントからは最低3台分のEC2の料金が完全に消えることになります。 これは、AWSのインフラコストを劇的に節約・削減できるというHCP方式だけの大きなメリットになります。 クラスター作成速度の向上 従来のClassic方式では、クラスターを新規作成するたびに、ユーザーのAWS環境内でコントロールプレーンのインフラも一から組み立てる必要がありました。そのため、クラスターが完全に起動して利用可能になるまでに、約30分〜40分ほどの待ち時間が発生していました。 HCP方式では、コントロールプレーンの構築・プロビジョニングがRed Hat側の環境で迅速に行われます。 ユーザーのAWS環境内では、アプリケーションを動かすためのワーカーノードのみを作成すれば良いため、クラスターの作成時間が約10分程度へと大幅に短縮されました。急ぎで新しい環境が必要になったりするビジネスシーンにおいて、このような時間の短縮は大きなメリットになります。 アップグレードの柔軟性 従来のClassic方式では、コントロールプレーンとワーカーノードのバージョンアップを密に連動させて管理する必要がありました。そのため、互換性の確認や影響範囲の調査を慎重に行わなければならず、事前の計画や検証に多くの工数を割く必要がありました。 HCP方式では、コントロールプレーンとワーカーノードの管理が完全に切り離されていますので、両者のアップグレードを別々のタイミングでスケジュールすることも可能です。 例えば、まずはRed Hat側が管理するコントロールプレーンだけを先行してアップデートし、アプリケーションが動くワーカーノードは業務影響の最も少ない別の日時に実施する、といった柔軟な運用ができるようになりました。   以上が、ROSA Classicと比べたHCP方式の特徴とメリットの解説になります。最後に、これまでご紹介した内容を表で簡単にまとめます。 ROSA ClassicとROSA HCPの比較表 比較項目 ROSA Classic（従来方式） ROSA with HCP（最新モデル） コントロールプレーンの配置 ユーザー自身のAWSアカウント Red Hat側 マスターノードのEC2費用 ユーザー負担 ユーザー側の負担ゼロ（Red Hat側で稼働するため） クラスター作成時間 約40分 約10分 アップグレード調整 両ノードが連動しているため、スケジュールの調整がしづらい 別々のタイミングで柔軟に調整・実行が可能 まとめ 以上、ROSAの概要から、現在の主流である「HCP（Hosted Control Planes）」の特徴と数々のメリットについてご紹介しました。 ROSA with HCPは、コスト・速度・運用のすべてにおいて優れており、現在のROSA構築におけるベストプラクティスとなっています。 これから新しくコンテナ基盤を検討される方に、この記事の内容が参考になれば幸いです。 次回は、実際にAWS上でROSA with HCPのクラスターを構築していく手順を詳しく解説します。ぜひ楽しみにしてください。 参考資料 AWS での Red Hat ソリューション Overview of responsibilities for ROSA ROSA HCP and ROSA classic Capability Matrix （ログイン必要） ROSA Best Practices and Recommendations Red Hat OpenShift Service on AWS 4 Introduction to ROSA ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ROSA（Red Hat OpenShift Service on AWS）を利用したコンテナプラットフォーム構築 ~ROSAの特徴とメリット~ first appeared on SIOS Tech Lab .

こんな方へ特におすすめ セキュリティ対応において、何から手をつければいいか迷っている方 HSTSなどのセキュリティヘッダ導入が、他の環境（検証環境など）に与える影響を知りたい方 概要 こんにちは。サイオステクノロジーのはらちゃんです！ 今回はSL代表としてセキュリティスキャン対策のコミュニケーションチームに入りました。 そこで得た「現場でのリアルな立ち回り」「セキュリティ対応の基本となる考え方」「HSTS導入時の思わぬ落とし穴（副作用）」といった、実務に直結する知見をまとめていきます。 背景 ある日、内部的なセキュリティスキャンが実施され、レポートが提供されました。 結果は「外部から容易に利用されるサイトで、改善が必要な項目が多々ある」という厳しいものでした。 最終的に、各SLで担当者を立てて全社的に修正対応を図ることになりました。 対応前のマインドセット 実際の技術的な修正に入る前に、チーム全体で以下の「考え方のポイント」を共有しました。無駄な作業を減らすための非常に重要なステップです。 「廃止・退役できるリソースか？」を最初に問う これが最もコストがかからず、最も安全な究極のセキュリティ対策。 使っていない検証環境は、修正するのではなく消すのが正解。 「対応しない」なら客観的な根拠を システム上の都合でどうしても対応できない項目もある。 しかし、放置するのではなく「なぜ対応できないか（客観的に妥当な根拠）」を言語化し、ディスカッションのテーブルに上げることが求められる。 オープンなコミュニケーション 専用のSlackチャンネルを用意し、不明点や気づきはすぐに共有する体制を作成。 3つの対応ポイント 指摘事項は多岐にわたりましたが、大きく以下の3点に分類して対応を進めました。 1. OS・パッケージの脆弱性対応 対応 サポートされている最新版に遅滞なく更新する。 ツール Amazon Inspector + AWS Security Hub CSPM（EC2やECRのDockerイメージの脆弱性を可視化）。 2. 伝送経路（SSL / TLS）の修正 対応 TLS1.0 / 1.1などの古いプロトコル、脆弱な暗号スイート（cipher）を無効化する。 IE11対応などの特殊な要件がない限り、2026年現在では TLS 1.2 / TLS 1.3 中心 で問題なし。 ツール Mozilla SSL Configuration Generator で安全なconfigを作成し、 SSL Labs で評価を確認。 3. セキュリティヘッダの指定 対応 Webサーバー（またはCDN）にCSPやHSTSなどのヘッダを追加する。 ツール securityheaders.com でのチェック。 ここが一番の難所でした。特にCSP（Content Security Policy）は、設定を間違えると必要なJSやCSSが読み込まれずサイトが壊れるため、技術開発センターの管理下サイトで先行検証・適用を進めるという慎重なアプローチをとりました。 そして、私のSLに最も影響を与えたのが HSTS です。 課題 HSTSポリシーと「自己署名証明書」の衝突 HSTS（HTTP Strict Transport Security）は、ブラウザに対して「今後は絶対にHTTPSで接続しろ」と強制する強力なセキュリティヘッダです。 ベストプラクティスとしては、以下の指定が推奨されます。 max-age で1〜2年以上の長期間を指定 preload 指定 includeSubDomains 指定（サブドメインも全てHTTPS強制） ここで問題発生です。依頼事項として「 [社内検証用サブドメイン配下] でHTTP接続しているリソースはないか？」という確認がありました。最終的にSSL接続が必須になります。 私のSLでは、以下の社内検証環境が稼働していました。 OpenShift検証環境 自動構築で「自己署名証明書（オレオレ証明書）」を利用。 社内検証Rancher/GitLab環境 内部DNS設定で、 [社内検証用サブドメイン配下] を利用。 HSTSが引き起こす「副作用」 本番ドメインにHSTSの includeSubDomains が付与されると、それにアクセスしたブラウザはポリシーを記憶します。 その後、同じブラウザで社内検証環境にアクセスすると、ブラウザは「HTTPSでの接続」と「正当な証明書の提示」を厳格に要求します。 そうすると、検証環境で使っている自己署名証明書がブラウザに強固にブロックされ、アクセス不可になるという懸念が浮上したのです。 検討案 HSTSの副作用をどう回避するか？ 検証環境のために本番のセキュリティレベルを下げるわけにはいきません。私たちは以下の回避策を検討しました。 正規の証明書を自動発行する Let’s Encrypt (DNS-01認証): Route53と連携して証明書の取得・更新を全自動化する。 AWS Certificate Manager (ACM): AWS環境であれば、ACMで発行した証明書をALB等に割り当てるのが最もスマート。 社内検証・開発用ドメインを物理的に分ける 本番ドメインのサブドメインを使わず、検証専用の別ドメインを取得する。 GoogleやFacebookなどの大手テック企業も採用している王道のアプローチ。 再構築のタイミングでドメインを変更する（期間区切り） 「10月までは今の環境を使い、それ以降は新規作成する」という場合、次回の再構築時にドメイン構成を見直すというリスク受容の判断もアリ。 プライベートCAを構築する 社内用の認証局を立てる案だが、構築・維持のコストリスクが高いため優先度は低め。 まずは「影響を小さく検証」する 様々な理想論を挙げましたが、机上の空論で終わらせず、まずは「実際のブラウザ挙動」を確かめるスモールスタートを切ることにしました。 【決定したネクストアクション】 技術管理担当者が、 sios.jp に HSTS ポリシー（ includeSubDomains あり）を適用する。 Slackで連絡を受けたら、インフラ担当者がブラウザで sios.jp にアクセスし、HSTSポリシーを学習させる。 そのまま検証環境へアクセスし、HTTPS強制ブロックの挙動を確認する。 回避策の検証 HSTSポリシーを共有しない「シークレットモード」や「別プロファイルのブラウザ」を利用することで、自己署名証明書の検証環境へアクセス可能か（業務への影響を回避できるか）をテストする。 まとめ セキュリティスキャンからの指摘は、一見すると「ただの面倒な作業」に思えるかもしれません。 しかし、今回のように「なぜHSTSのサブドメイン指定が検証環境を壊すのか？」「どうやって回避するのか？」をチームで議論することで、インフラ設計の解像度がグッと上がります。 不要なリソースは捨てるのが最強のセキュリティ。 HSTS導入時は、サブドメインで動いている検証環境（自己署名証明書）の死に直結しないか注意する。 理想のアーキテクチャ（ドメイン分離やACM活用）を描きつつも、まずはプライベートブラウザ等の運用回避で業務を止めない立ち回りも重要。 今後も、こうした全社的な取り組みを通して得られた知見を、皆さんに共有していきたいと思います！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post セキュリティスキャン指摘対応 | HSTS導入の影響と回避策 first appeared on SIOS Tech Lab .

はじめに 前回はKubernetesのバックアップは、etcdとPV/PVCの二軸で、セットで行うことが重要であることを解説しました。しかし、ステートフルなアプリケーションのバージョンアップでは、データの互換性と整合性が課題となります。 本記事では、これらの複雑な課題を解消し、安全なリソースとデータのバックアップ・リストアを実現するソリューションである「Velero」について解説します。 Veleroの基本コンセプトとアーキテクチャ Velero（旧称 Heptio Ark）は、Kubernetesクラスターリソース（マニフェストファイル）と永続ボリューム（PV）のデータの両方をまとめてバックアップ/リストアを実現するツールです。 Kubernetesのバックアップでは、アプリケーションを構成するすべてのクラスターリソースをバックアップするだけでは不十分で、データ（永続ボリューム）も同時に保存する必要があります。これは、Veleroを使うことで実現可能です。 さらに、クラウドプロバイダーの変更やオンプレミスからクラウドへの移行、Kubernetesのメジャーバージョンアップに伴う新しいクラスターへのデータ移行といった複雑で時間がかかる作業もVeleroでは対応可能になります。 Veleroは以下の用途で利用できます。 クラスターのバックアップを取得し、データ損失が発生した場合にリストアを行う クラスターリソースを他のクラスターへ移行する 本番クラスターを開発/テストクラスターへ複製する Kubernetesのアップグレードなどのシステム操作を実行する前に、アプリケーションの状態をスナップショットする Veleroの主な特徴 クラスター内のすべてのオブジェクトをバックアップまたはリストアできる。オブジェクトタイプ、ネームスペース、ラベルによるフィルタリングも可能 バックアップ、リストア、スケジュールといったすべての操作の定義がKubernetesのカスタムリソースとして定義され、etcdに保存される クラウドプロバイダーまたはオンプレミスのKubernetes環境で動作可能 独自のカスタム機能をVeleroに追加できるプラグインシステムが提供されている PVのバックアップ方式 Veleroは、永続ボリューム（PV）のデータを保護するために、主に以下の3つの方式をサポートしています。ファイルシステムバックアップ（FSB）とスナップショットは、同一ボリュームに対して同時に実行されず、相互に排他的な関係になります。 方式 概要 主な用途 ボリュームスナップショット クラウドプロバイダー（AWS EBS, Azure Disk等）やCSIドライバーが提供するネイティブなスナップショット機能を利用する。 主要なクラウドプロバイダーやCSI準拠のストレージを利用している場合の標準的なデータ保護。 ファイルシステムバックアップ (FSB) Node Agent (Kopia Uploader) と呼ばれるDaemonSetが各ノードで稼働し、ボリュームのファイルシステムを直接読み取り、オブジェクトストレージにデータを保存する。 NFSのような共有ファイルシステムや、CSIドライバーが提供するスナップショット機能を持たないストレージのデータ保護。プロバイダー間の移行に利用可能。 CSIスナップショットデータムーバー CSIスナップショットで作成されたデータを、Node Agent経由でオブジェクトストレージに移動・コピーする。 クラウドプロバイダ間のデータ移行、オンプレミスからクラウドへのデータ移行、スナップショットデータの長期アーカイブ。 Veleroアーキテクチャ Veleroの主要リソースは以下の通りです。 バックアップ、リストア、スケジュールといった操作はクライアントのVelero CLIから実行します。 主要リソース 役割 実行環境 Velero サーバー メインコントロールプレーン。バックアップ/リストアのロジック、リソースの収集、オブジェクトストレージへの連携を担当する。 Kubernetesクラスター内のDeployment。 Node Agent ファイルシステムバックアップ（FSB）やCSIスナップショットデータムーバーなどのデータ転送を担う。 Kubernetesクラスター内のDaemonSet。 BackupStorageLocation (BSL) KubernetesリソースのメタデータやPVデータ（FSB/データムーバー利用時）の保存場所（オブジェクトストレージ）を定義する。 オブジェクトストレージ（AWS S3、Azure Blob、MinIOなど）。 VolumeSnapshotLocation (VSL) PVスナップショットの保存場所を定義。 CSIドライバー対応のスナップショットシステム。 バックアップのワークフロー VeleroによるKubernetesリソースと永続ボリュームのオンデマンドバックアップのワークフローは以下になります。 Image Source: https://velero.io/docs/v1.17/how-velero-works/ VeleroクライアントがKubernetes APIサーバーを呼び出してBackupオブジェクトを作成する BackupControllerが新しいBackupオブジェクトを認識して、検証を行う BackupControllerがバックアッププロセスを開始する。APIサーバーにリソースを照会してバックアップするデータを収集する 収集したオブジェクトをtar形式にアーカイブし、BackupControllerがオブジェクトストレージサービス（AWS S3など）を呼び出して、バックアップファイルをアップロードする 永続ボリューム（PV）が存在する場合、連携するストレージプロバイダのAPIを呼び出し、ボリュームのスナップショットを作成する フック（Backup Hooks）が設定されている場合、カスタムアクション処理の前（pre hook）または、すべてのカスタムアクション完了および追加アイテムのバックアップ完了後（post hook）に、Pod内のコンテナでコマンドが実行される スケジュールされたバックアップは、Cron式で指定された間隔で自動的に実行される Veleroのフック（Hook）機能とは？ データベースのようなアプリケーションは、DBのバックアップ中にデータが書き換わると整合性が取れなくなる可能性があります。Veleroのフック（Hook）機能は、この問題を解決するために、バックアップ処理に合わせてコンテナ内で任意のコマンドを実行する機能です。例として、Veleroのフック機能は以下のようなことが可能です。 Pre-hook（直前）：データの書き込みをロックし、静止点を作成 Post-hook（直後）: バックアップ完了後にロックを解除し、通常稼働に復帰 Veleroでのリストア VeleroによるKubernetesリソースと永続ボリュームのリストアのワークフローは以下になります。 VeleroクライアントがKubernetes APIサーバーを呼び出してRestoreオブジェクトを作成する RestoreControllerが新しいRestoreオブジェクトを認識して、検証を行う RestoreControllerがオブジェクトストレージサービスからバックアップ情報を取得する。次に、バックアップされたリソースに対して前処理を行い、リソースが新しいクラスターで動作することを確認する RestoreControllerがリストアプロセスを開始する。依存関係を考慮した適切な順序で対象となるリソースが1つずつ復元される フック（Restore Hooks）が設定されている場合、以下のタイミングでリストアされるPod内のコンテナに対して実行される InitContainer：リストアされるPodにInitコンテナを追加して、アプリケーションコンテナが開始される前に必要なセットアップを実行する。PVと紐づく場合は、PVのリストア後に実行される Exec：リストアされたPodのコンテナが起動した後、コンテナ内でカスタムコマンドまたはスクリプトが実行される デフォルトではリストア時にターゲットクラスタ上のデータは削除されません。バックアップ内の同名リソースがターゲットクラスタ内に既に存在する場合は、そのリソースをスキップします。「update」フラグがある場合、リソースを更新します。 他のバックアップ手法との比較 VeleroはKubernetesネイティブなOSSバックアップソリューションです。他のKubernetesのバックアップソリューションとしては、Cohesity、Commvault、Rubrikが挙げられますが、いずれもエンタープライズ向け包括バックアップ製品の一機能としてKubernetesのバックアップ機能を提供しています。 Cohesity 初回以降は変更分のみをバックアップする永久増分バックアップを採用しており、バックアップ時間の短縮とネットワーク・ストレージ負荷の低減が強みです。 Commvault AKS/EKS/Openshiftなどのマルチクラウド、マルチディストリビューションのクラスターを1つの画面で統合管理できます。アプリ単体だけでなく、クラスタ全体を保護できる広範なバックアップが特徴です。 Rubrik 書き換え不可能な（不変）バックアップとゼロトラストアーキテクチャを採用し、ランサムウェア対策と整合性を提供しています。アプリとデータ状態の整合性を厳密に保ったままバックアップできる点が強みです。 Kubernetesだけを低コストでバックアップしたい場合はVeleroが第一候補に挙がります。既にCohesity、Commvault、Rubrikを使用している、またはKubernetes以外もバックアップ対象に含めたい場合は既存・導入予定のプラットフォームに寄せる方が現実的です。 まとめ 本記事では、Kubernetesのリソースと永続ボリュームを包括的に保護できるVeleroについて解説しました。Veleroは、Hook機能を利用してデータベースの整合性を確保できる点や、環境に応じてスナップショットとファイルシステムバックアップを使い分けられる柔軟性が強みです。 次回は、実際にVeleroをKubernetesへ導入するための構築手順と設定方法について詳しく解説します。 参考文献 https://velero.io/docs/v1.17/ https://github.com/vmware-tanzu/velero https://www.cohesity.com/ja-jp/solutions/kubernetes/ https://www.commvault.com/platform/kubernetes-backup https://www.rubrik.com/ja/solutions/kubernetes ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Kubernetesバックアップツール「Velero」の概要 first appeared on SIOS Tech Lab .