こんな方へ特におすすめ セキュリティ対応において、何から手をつければいいか迷っている方 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 .

はじめに 前回の記事では、GitLabとOpenShift、Gatekeeperを組み合わせたDevSecOpsモデルケース環境の構築方法を紹介しました。   本記事では、それらを組み合わせて閉域環境におけるDevSecOpsモデルケースを構築し、デモアプリを使ってCI/CDの流れにセキュリティがどのように組み込まれるのかを確認します。   金融や公共分野など高いセキュリティ要件が求められるシステムでは、インターネット非接続の環境であっても、開発のスピードと安全性を両立することが求められます。 GitLabとGatekeeperを活用することで、この課題をどのように解決できるのかを具体的に示すのが今回の目的です。 DevSecOpsとは、DevOpsの迅速な開発・運用プロセスに「セキュリティ」を組み込み、スピードと安全性を両立させる手法です。従来は「開発が完了した後にセキュリティチェックを行う」ことが一般的でした。しかしこの方法では、最終段階で脆弱性が見つかった際に大きな修正が必要となり、時間やコストの増大、リリースの遅延を招いてしまいます。 DevSecOpsでは、開発ライフサイクルの各段階にセキュリティを統合することで、早い段階からリスクを検知し、小規模な修正で対処できます。その結果、開発のスピードを維持しながら、コスト削減と安全性の向上を同時に実現できます。 DevSecOpsは、下図のように開発（Dev）と運用（Ops）のライフサイクルにセキュリティ（Sec）を組み込む考え方です。 DevSecOpsの詳細については以下の記事で解説していますので、ご参照ください。 DevSecOpsとは？安全性とスピードを両立する開発手法 | SIOS Tech. Lab 本記事のデモは、以下の流れで進めます。 ゴール 本記事のゴールは次のとおりです。 DevSecOpsのライフサイクルを実際のCI/CDパイプラインを通じて理解する GitLabとGatekeeperを組み合わせたセキュリティ統制の仕組みを把握する 前提条件 本記事のデモンストレーションは、以下の環境を前提としています。 GitLab サーバー（ソースコード管理・CI/CD実行） OpenShift クラスター（閉域環境にて構築済み、アプリケーション実行環境） GitLab Runner（OpenShift 内にデプロイ済み） Gatekeeper（OpenShift 内にデプロイ済み、リソース作成許可ポリシーを定義済み） 踏み台サーバー（クラスターへのアクセス用） これらは前回の記事「 構築編 」で構築したモデルケース環境に含まれています。 構築手順の詳細は「構築編」を参照してください。 デモアプリの仕様 ベースイメージ：nginx サービス提供ポート：8080 到達性：内部ネットワークのみアクセス可能（外部公開なし） デプロイ方式：Helm（Chart・valuesでイメージタグを切り替え） デモで使用するタグ：v1.0（初回デプロイ）、v1.1（修正デプロイ） パイプラインの実行フロー 今回利用するCI/CDパイプラインの実行フローは以下の通りです。 ビルド用パイプライン実行フロー 開発者がGitLabのビルド用プロジェクトにブランチをマージ マージをトリガーとして、GitLab CI/CDパイプラインが起動 GitLab CI/CDからOpenShiftクラスター内のGitLab Runnerへビルドジョブ実行リクエストを送信 RunnerがジョブPodを起動 ジョブPodがビルド用プロジェクトからアプリのソースコードをClone ジョブPodがdocker CLIなどを利用してコンテナイメージをビルド ジョブPodがビルドしたイメージをGitLabのビルド用プロジェクト内のレジストリにpush デプロイ用パイプライン実行フロー 開発者がGitLabのデプロイ用プロジェクトにブランチをマージ マージをトリガーとして、GitLab CI/CDパイプラインが起動 GitLab CI/CDからOpenShiftクラスター内のGitLab Runnerへデプロイジョブ実行リクエストを送信 RunnerがジョブPodを起動 ジョブPodがOpenShiftのAPIサーバーに対し、リソースのデプロイリクエストを送信 APIサーバーがGitLabのレジストリからアプリのイメージをpull APIサーバーがOpenShiftクラスター内にアプリをデプロイ DevSecOpsのデモンストレーション ここからは、構築済みのモデルケース環境を使って、実際にDevSecOpsの流れを確認します。 以下のように、アプリのデプロイを2回繰り返し、最後にGatekeeperによる制御を体験します。 アプリの初回アップロード（v1.0 デプロイ） アプリを修正して再度デプロイ（v1.1 デプロイ） Gatekeeperによる不正リソース作成の拒否 アプリケーションの初回デプロイ ここからは、DevSecOpsライフサイクルのCode → Operate（1週目）に対応します。 まず、アプリの初回デプロイを行います。 コードを ビルド用プロジェクト のfeatureブランチにpushし、developブランチへマージします。 developブランチにマージすると、コンテナイメージをビルドするパイプラインが起動します。 この操作によって、開発用のイメージ（dev-v1.0）がビルドされます。  続いて、 デプロイ用プロジェクト のfeatureブランチをdevelop ブランチへマージします。 これにより、先ほどビルドされたv1.0イメージを利用して、開発用Namespaceにアプリがデプロイされます。 $ oc get pod -n devsecops-develop -l app="nginx" NAME                                READY   STATUS    RESTARTS   AGE nginx-deployment-5d75b659c5-cqbqp   1/1     Running   0          118s 動作確認が完了したら、ビルド用プロジェクトのdevelopブランチからmainブランチへのマージリクエストを作成し、承認後にマージします。 mainブランチにマージすると、パイプラインが起動し、prod-v1.0イメージがレジストリに格納されます。 次にデプロイ用プロジェクトでdevelopブランチをmainブランチにマージすると、パイプラインが起動し、本番環境用のネームスペースにアプリをデプロイします。 その結果、本番環境にアプリがデプロイされ、表示内容を確認できれば、 Code → Operate の1週目（v1.0）が完了 です。 $ oc get pod -n devsecops-production -l app="nginx" NAME                                READY   STATUS    RESTARTS   AGE nginx-deployment-6c49676b47-m96pf   1/1     Running   0          29s nginx-deployment-6c49676b47-pzv96   1/1     Running   0          29s アプリケーションを修正して再度デプロイ ここからは、DevSecOpsライフサイクルのCode → Operate（2週目）に対応します。 アプリを修正します。ここではindex.htmlの内容を更新し、あわせて.gitlab-ci.ymlで定義しているコンテナイメージのタグをv1.1に変更します。 次に、 ビルド用プロジェクト のfeatureブランチにpushし、developブランチへマージします。 この操作によって、新しい開発用イメージ（v1.1）がビルドされます。 続いて、 デプロイ用プロジェクト のfeatureブランチでConfig/develop-values.yamlと Config/product-values.yamlのtagを修正し、反映します。その後、同様にdevelopブランチ へマージして変更を適用します。 これにより、先ほどビルドされたv1.1イメージを利用して、開発用Namespaceにアプリがデプロイされます。 $ oc describe pod -n devsecops-develop nginx-deployment-54d94596b6-8j8w6 | grep "Image:"     Image:          registry.gitlab.local.example.com/devsecops-user/devsecops-build-project/nginx:dev-v1.1 動作確認が完了したら、developブランチからmainブランチへのマージリクエストを作成し、承認後にマージします。 その結果、本番環境に修正版アプリがデプロイされ、表示内容が更新されていることを確認できます。 $ oc describe pod -n devsecops-production nginx-deployment-59ddc6dbb6-lhd6b | grep "Image:"     Image:          registry.gitlab.local.example.com/devsecops-user/devsecops-build-project/nginx:prod-v1.1 この時点で、 Code → Operate の2週目（v1.1）が完了 です。 Gatekeeperによる不正リソースの検知・拒否 ここからは、DevSecOpsライフサイクルのSecに対応します。 最後に、あえて不正な設定を持つリソースをNamespaceにデプロイしてみます。 Gatekeeperのポリシー設定で、 envラベルの値がデプロイ先のnamespace名と一致していないとPodの作成を許可しない 制約 を設定しています。 以下のように、 デプロイ用プロジェクト でdeploymentのlabelsでenvラベルを不正な値に書き換える修正を行い、developブランチにマージします。 このときGatekeeperのポリシーが働き、不正なリソースの作成は拒否されます。 実際のログやイベントを確認すると、Constraint によって違反が検出され、Podのデプロイが失敗していることが分かります。   一番下のReplicaSetはDesired 1に対して、Currentが0であり、Podがデプロイされていないことがわかります。 $ oc get replicasets.apps -n devsecops-develop  NAME                          DESIRED   CURRENT   READY   AGE nginx-deployment-54d94596b6   1         1         1       20m nginx-deployment-5d75b659c5   0         0         0       14h nginx-deployment-6bfd599796   1         0         0       3m48s PodがデプロイされていないReplicaSetのイベントを確認すると、Gatekeeperの 制約テンプレート で設定したエラーメッセージが表示されていることがわかります。 $ oc describe replicasets.apps -n devsecops-develop nginx-deployment-6bfd599796 Events:   Type     Reason        Age                 From                   Message   ----     ------        ----                ----                   -------   Warning  FailedCreate  4m13s               replicaset-controller  Error creating: admission webhook "validation.gatekeeper.sh" denied the request: [require-env-label-match-namespace] Pod 'nginx-deployment-6bfd599796-z7hgf' の 'env' ラベルの値は、Namespace名 'devsecops-develop' と一致する必要があります。現在の値は 'dummy-env' です。 このように、 開発者が意識しなくてもポリシー違反が自動的にブロックされる ことで、セキュリティを犠牲にせずに CI/CD のスピードを維持できることを体験できます。 まとめ 本記事では、GitLab、OpenShift、Gatekeeperを組み合わせて閉域環境にDevSecOpsモデルケースを構築し、デモアプリを用いて以下の流れを確認しました。 GitLab CI/CDによるアプリケーションデプロイの自動化   コード変更からの継続的デリバリー   Gatekeeperポリシーによるセキュリティ担保   このデモを通じて、次のポイントを押さえることができました。 DevOpsだけでは不十分 開発サイクルが迅速化しても、不正なリソースや設定が混入すれば安全性は損なわれる。 ポリシー制御の仕組みが重要 Gatekeeperを用いることで、開発の初期段階から不正なリソースを自動的に排除できる。 GitLabとOpenShiftの統合は実用的 インターネット非接続の閉域環境でも再現可能であり、金融・公共分野を含む実案件にも応用できる。 さらに実環境での利用を考えるなら、コンテナイメージのセキュリティスキャンや、より複雑なポリシー制御を組み合わせることで、より強固なDevSecOpsを実現できます。   まずは小規模なモデルケースから試し、徐々に自社の環境や要件に合わせて拡張していくことをおすすめします。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post DevSecOps実践ガイド：セキュアなCI/CD運用の実践編 first appeared on SIOS Tech. Lab .