Technical Blog テクニカルブログ
  1. HOME
  2. テクニカルブログ
  3. 【NIC x Ops(にこぷす)通信】(Terraform編)【連載】本当に買い?HCP Terraform Premiumをゆるっと検証 〜気になる「運用自動化」と「ガバナンス」ってぶっちゃけどうなの?(全6回)

【NIC x Ops(にこぷす)通信】(Terraform編)【連載】本当に買い?HCP Terraform Premiumをゆるっと検証 〜気になる「運用自動化」と「ガバナンス」ってぶっちゃけどうなの?(全6回)

投稿者:種田

【第2回】プレミアムの画面、全部見せます!Premiumプラン限定機能ツアー

目次

  1. 導入:Premiumの世界へようこそ(全体俯瞰)
  2. 画面ツアー①:【組織(Organization)設定】編
  3. 画面ツアー②:【プロジェクト(Project)設定】編
  4. 画面ツアー③:【ワークスペース(Workspace)設定】編
  5. 次回予告

皆さま、こんにちは!
このテックブログでは、IT運用に関する内容を連載、「にこぷす通信」をお届けしています。

「NIC x Ops(にこぷす)」とは?

NIC x Ops(にこぷす)』とは、
私たちの会社であるNTTインテグレーション(NI+C)の運用ノウハウと、
IBMさんの強力なソリューションを
Collaboration(コラボレーション)させた、IT運用高度化シリーズ(Ops)のニックネームなんです。

現代のIT運用の現場は、システムの複雑化や人手不足など、課題が山積みです。そんな現場を少しでも楽に、そしてエンジニアの皆さんが笑顔で「攻めの運用」ができるように支えたい。そんな想いがこの「にこぷす」には込められています。

「にこぷす」には、Instana(可観測性)のほかにも、Turbonomic(リソース最適化)Terraform(インフラ自動化)など、IT運用を劇的に変える製品がたくさんあります。

これからもこの通信を通して、「IT用語は難しいけれど、中身を知ればこんなに便利で面白いんだ!」というテクニカルな内容をご紹介していきますので、どうぞよろしくお願いします。

1. 導入:Premiumの世界へようこそ(全体俯瞰)

Premiumに上がった瞬間、サイドバーのメニューが肉厚になります。今回は『組織』『プロジェクト』『ワークスペース』の3つの階層ごとに、何が増えて、現場の運用がどう変わるのかを見ていきましょう!(UI は執筆時点(2026年7月)の情報に基づきます)

1.1. メニューの違い:組織 レベル

まずは組織レベルから。組織のルートに差異はない様です。

Setting の中身を見てみましょう。組織設定、セキュリティでそれぞれ2つずつ、合計4つ項目が増えていますね。

1.2. メニューの違い:プロジェク トレベル

続いて、プロジェクトレベルを見ていきましょう。こちらもルートは差異はありません。

Setting では3つ項目が増えました。チームの概念もプロジェクトレベルから出現してきていますね。

1.3. メニューの違い:ワークスペース レベル

どんどんいきましょう。ワークスペースではルートの時点で差異があるようです。

Setting でも3つ項目が増えています。

1.4. メニューの違い(まとめ)

ざっくりまとめるとこんな感じになります。

項目 組織設定 プロジェクト
設定
ワークスペース
(ルート)
ワークスペース
設定
機能概要
Health インフラの健全性や実際の構成との乖離(ドリフト)を一元的に監視・検知する機能。
※ ワークスペースのルートのものは状態を表示するダッシュボード機能
Recoverable items 削除されたワークスペースやスタックを30日間保持し、元の状態に復旧できる誤削除防止機能。
Auditing 組織内で行われたすべての操作ログ(監査ログ)を記録・閲覧・エクスポートする機能。
HYOK encryption 独自に管理する暗号化キーを用いて、ステート等の機密データを高度に保護するセキュリティ機能。
Team access チームごとの詳細なアクセス権限(RBAC)を、プロジェクトまたは個別ワークスペース単位で制御する機能。
Auto-destroy workspaces 指定日時や無操作期間に応じてインフラを自動破棄(TTL設定)し、無駄なリソースコストを削減する機能。
Notifications プロジェクト内の全ワークスペースに対し、SlackやWebhookなどの通知ルールを一括適用する機能。
Actions ワークスペースに対してあらかじめ定義されたカスタムタスクや、任意の管理操作を迅速に実行する機能。
Change requests コード変更やモジュール更新の要求を記録し、チーム内でのレビューや承認フローを管理する機能。

Premiumプランによって拡張されるメニューは、大きく分けて以下3つの目的(ガバナンス・自動化・リスク管理)に分類できます。

1. ガバナンスとセキュリティの強化のための機能(守りを固める)

Auditing(監査ログ)や、詳細なアクセス制御ができるTeam access(RBAC)により、「誰が・いつ・何をしたか」を正確にトラッキングし、適切な権限管理を実現します。また、HYOK encryptionを利用することで、ステートファイルなどの機密データを独自の暗号化キーでより強固に保護できます。

2. 運用自動化とコスト最適化のための機能(手間と無駄を省く)

検証環境の消し忘れを防ぐAuto-destroy workspaces(自動破棄)は、無駄なクラウドリソースコストの削減に直結します。さらに、Notifications(通知)の一括設定や、定型作業を迅速に実行できるActionsを活用することで、日々のインフラ運用にかかる手作業を大幅に自動化・効率化できます。

3. リスク管理と信頼性の向上のための機能(事故を防ぎ、安全を保つ)

実際のインフラ構成とのズレを検知するHealth(ドリフト検知)をはじめ、誤って削除した環境を30日間保持するRecoverable items(復旧機能)、コード変更時の承認フローを回せるChange requestsなど、チーム開発における事故を未然に防ぎ、インフラの健全性を保つセーフティネットが充実しています。

次の章では「手作業の限界」や「チーム開発の壁」を越えるための、強力な機能たちの役割を見ていきましょう。

2. 画面ツアー①:【組織(Organization)設定】編

この章では、最上位の階層である「組織(Organization)」レベルで追加されるメニューを一挙にご紹介します!
ノーコード機能の入り口であるRegistryから、詳細な権限設定ができるTeams、万が一のためのRecoverable Itemsや暗号化設定まで、Premiumならではの強力な管理画面を一緒に巡っていきましょう!

2.1. Registry

メニューから「Registry」→「Private Library」の順に選択すると、Premium では「No-Code Provisioning(ノーコード・プロビジョニング)」の案内が大きく出現します。
インフラの知識が浅いメンバーでもポチポチ環境を作れるという、Premium の機能です!詳しい使い方は次回の第3回で検証するので、ここでは「ここにこんなものが表示されるんだな〜」と眺めるだけでOKです!

2.2. Explorer

お次のメニューは、組織内のワークスペースやリソースを一元的に見渡せる「Explorer」画面です!

ここを開いてまず気づくのが、画面上部の検索条件や分類を指定する「Use Case」の部分。Premium で提供される機能に合わせて、項目が2つ多く追加されているのが分かります。

次に、Explorer から Workspace を表示させてみました。

ワークスペースのリストの左端に注目です(スクショの赤枠部分)。 Premium プランでは、各ワークスペースの横に専用のチェックボックスが出現します!

変更を加えたいワークスペースにチェックを入れると……画面の右下に、青い 「Create change request」 というボタンが現れる仕組みになっています。

この青いボタンを押すと、Change Request(変更要求)の登録画面へと進むことができます!

「Change request」とは、「どの環境に、どんな修正タスクが残っているのか」を外部の管理ツールに頼らず、Terraformの中で完結させて管理しやすするための機能になります。
画面のリストから直感的にチェックを入れて、安全な承認プロセスを始められる、現場目線でも非常に使いやすい親切な導線になっています。

2.3. Settings / Teams

続いては、組織設定の中にある「Teams」のメニューを見ていきましょう! Premiumプランでは組織内で複数のチームを柔軟に作って管理できるため、メニューを開くとまずはチームの一覧(Team management)画面が表示されます。

2.3.1. Settings / チーム名 / General

ここで特定のチームを選択して詳細画面に進むと、そのチームに付与する権限をコントロールする詳細設定画面に切り替わります。
無料枠に比べて、設定できる項目の細かさが桁違いなのが有償版の特徴。この画面でチームに対する詳細な制御(RBAC)が設定できます。

具体的にどんな項目が並んでいて、それぞれどんな役割を持っているのか、一覧表にサクッとまとめてみました👇

項目 種別 主な内容 プレミアム限定
Project permissions 選択式 組織内のすべての「プロジェクト」に対する操作権限を設定。
<選択肢>
  • None:権限を付与しない
  • View all projects:すべてのプロジェクトの参照権限を付与
  • Manage all projectsすべてのプロジェクトの管理権限を付与
Workspace permissions 選択式 組織内のすべての「ワークスペース」に対する操作権限を設定。
<選択肢>
  • None:権限を付与しない
  • View all workspaces:すべてのワークスペースの参照権限を付与
  • Manage all workspaces:すべてのワークスペースの管理権限を付与
Team permissions 選択式 他のチームや組織のユーザーを管理する権限を設定。
<選択肢>
  • None:権限を付与しない
  • Manage membership:メンバー管理権限を付与する
  • Manage teams:チーム管理権限を付与する
  • Manage organization access:組織へのアクセスの管理権限を付与する
Include secret teams チェックボックス 組織内に存在する、通常は見えない「隠しチーム」へのアクセスを許可するかどうか。
Policy overrides 選択式 ポリシー違反が検出された時に「例外として強制的にデプロイ(Apply)を進める」特権をこのチームに付与するかどうかを設定。
<選択肢>
  • No policy overrides:権限を付与しない
  • Delegate policy overrides:プロジェクトおよびワークスペースの管理者に評価の上書き権限を付与
  • Manage policy overrides:メンバーにすべてのワークスペースでにおける評価の上書き権限を付与
Settings permissions チェックボックス 組織全体に影響を与える設定を管理する権限を設定。
<設定可能な項目>
  • Manage policies:ポリシーの管理権限を付与
  • Manage run tasks:タスク実行の管理権限を付与
  • Manage version control settings:VCS Providers と SSH keys の管理権限を付与
  • Manage agent pools:エージェントプールの管理権限を付与
Private registry permissions チェックボックス Private registry の公開・削除や、それらを整理するタグ付けの権限を設定。
<設定可能な項目>
  • Manage modules:非公開モジュールの管理権限を付与
  • Manage providers:非公開プロバイダーの管理権限を付与
  • Manage Stack component configurations:Stack コンポーネントの管理権限を付与
  • project tag assignment:モジュール/プロバーダーへのプロジェクトタグの設定権限を付与
  • registry environment tag assignment:モジュール/プロバーダーへのレジストリー環境タグの設定権限を付与
Public registry permissions チェックボックス Public registry の公開・削除や、それらを整理するタグ付けの権限を設定する。
<設定可能な項目>
  • Manage public modules:公開モジュールの管理権限を付与
  • Manage public providers公開プロバイダーの管理権限を付与
Visibility 選択式 このチーム自体の存在の公開範囲を設定。
<選択肢>
  • Visible:組織全体に公開
  • Secret:チームメンバーとオーナーのみ
Team API tokens チェックボックス チームに所属するメンバーに、「Team API tokens」の発行や失効を許可するかどうかを設定する ×
Add a new team member プルダウン 組織内ユーザーの追加する機能
プルダウンから追加するユーザーを選択
×
Members リスト チームメンバーが一覧表示される領域 ×

2.3.2. Settings / 各チーム / Notifications

さらに、各チームの個別メニューには「General(基本設定)」のほかに、もう一つ「Notifications(通知)」というタブが用意されています。

通知を作成するボタンをクリックすると、Webhook、メール、Slack、Microsoft Teamsといった、普段の業務で使い慣れたチャットツールやシステムへの通知設定がずらりと並んでいます! チームに関連するイベントを適切なルートへ自動通知できるので、複数チームで並行して開発を進めるときの連携がスムーズになります。

2.4. Settings / Health

続いての設定メニューは「Health」です。
ここでは、Premiumプランの目玉機能の一つである「ドリフト検知(実際のクラウド環境とのズレの検知)」を、組織全体でどう有効化するか(適用範囲)を設定できます

画面中央のラジオボタンを見てみると、設定はとてもシンプルで以下の2択になっています。

  • Enable for all workspaces:組織内のすべてのワークスペースで一括・強制的に有効化する
  • Per workspace settings:ワークスペースごとに個別に有効・無効を設定できるようにする

「本番環境だけしっかりズレを検知したいな」という場合は Per workspace settings にして個別管理すれば良いですし、「野良変更は一切許さない!全環境一元管理だ!」という場合は Enable for all workspaces で一括強制しちゃうのがラクですね。

企業の運用ガバナンスの方針に合わせて、組織の「Health」画面で切り替えられるようになっています。

2.5. Settings > Recoverable Items

お次は「Recoverable Items」のメニューです。ここは、いわゆるワークスペースの「ゴミ箱」のような場所ですね。

私たちの検証環境ではまだ何も削除していないので、スクショのように「データがないよ(空っぽ)」という状態になっています。 ですが、もしメンバーが誤ってワークスペースを削除してしまっても、ここから30日間は元の状態にポチッと復旧(Restore)させることができます! 万が一の事故を防いでくれる、チーム開発にはめちゃくちゃ心強いセーフティネット機能です。

2.6. Auditing

お次は、エンタープライズ運用やセキュリティ監査では絶対に欠かせない「Auditing(監査ログ)」の画面です。
組織内で「誰が・いつ・何をしたか」という操作履歴を自動的にすべてレコーディングしてくれる、ガバナンスの要となるメニューです。

画面中央を見ると、緑色のチェックマークで「Active」と表示されていますね。 先ほど書いた通り、この監査ログ機能はPremiumプランであれば最初から自動的に有効化されてログのレコーディングが始まる仕様になっています。そのため、ユーザー側で難しい初期設定をする必要はありません。デフォルトで過去14日間の操作ログがしっかり保持されます。

実際の「誰が・いつ・何をしたか」という細かい操作履歴は、各ワークスペースのアクティビティ画面などで追跡することになりますが、その「裏側での自動録画」を組織全体で一元的に担保してくれているのがこの画面で確認できます。

画面にある青い「Send test event」というボタンを押すと、テスト用のログを1発飛ばして外部連携などのテストを行うことができます。 万が一のトラブルの際にも、「裏で確実に証拠(ログ)が残っている」という安心感を管理者に与えてくれる、頼もしい縁の下の力持ち機能です。

2.7. HYOK Encryption

組織設定編のトリを飾るのは、最高峰のセキュリティ機能「HYOK Encryption」です!

HYOKとは「Hold Your Own Key」の略。通常はHashiCorp側が管理している暗号化キーで保護されるstateファイルなどの機密データを、自分たちが管理するKMS(Key Management System)の暗号化キーを使ってガチガチに暗号化しちゃおうという金融機関やPCI DSS準拠などの要件のある企業向けの機能です。

まだキーが登録されていない初期状態では、画面中央に青い 「Configure a new key」 というボタンが表示されています。ここからデモ的に、設定画面のステップを順番にのぞいてみましょう!

青いボタンをポチッと押すと、まずは連携するクラウドのKMSプロバイダー(AWS、Google Cloud、Azureなど)を選択する画面に進みます。
今回の私たちの検証環境はGoogle Cloudベースなので、ここではGoogle Cloud KMSを選択していく流れになります。

Google Cloud KMSを選択すると、続いてHCP Terraform側から鍵へ安全にアクセスするための認証情報(サービスアカウントのメールアドレスやプロジェクト番号、ワークロードプロバイダー名など)を入力する画面に切り替わります。

企業のセキュリティポリシー上、「クラウドベンダー任せの暗号化ではなく、鍵の管理権限(失効権限など)は絶対に自社で握っておきたい!」という厳しい現場でも、この画面から必要な情報をポチポチ指定していくだけで、システム間の安全な紐付けが完了します。

認証情報の入力が完了して右下の「Next」ボタンを押すと、最終ステップである「Configure key settings(キーの最終設定)」の画面へ進みます。

ここでは、登録する暗号化キーに分かりやすい名前(Name)をつけたり、実際にどのワークスペースにこのHYOK設定を適用するかといった、運用上の最終的な落とし込みを行います。 画面の指示に従って「Create」まで進めば、最高水準のデータ保護環境のセットアップがすべて完了です!

以上で、最上位階層である「組織(Organization)設定」のPremium限定メニューツアーは終了です!

続いては、一つ下の階層となる「3. 画面ツアー②:【プロジェクト(Project)設定】編」に突入していきましょう。 プロジェクトレベルでのPremiumの差異はより細かくなったアクセス制御(権限管理)」がメインになります。現場のチーム運用にどう関わってくるのか、さっそく見ていきましょう!

3. 画面ツアー②:【プロジェクト(Project)設定】編

この章では、「プロジェクト(Project)」レベルで追加されるPremium限定メニューの差異をツアーします。
ここでの一番の見どころは、チームごとにめちゃくちゃ細かく権限をコントロールできるようになった「Team access(アクセス制御)」の画面です。 そのほか、運用の自動化に繋がるメニュー(自動破棄や通知など)の見た目もサラッと押さえつつ、Premiumならではの管理画面の裏側をチェックしていきましょう!

3.1. Settings / Team access

プロジェクト設定編の実質的な主役であり、ガバナンス強化の要となる「Team access」のメニューです!

ここを開くと、まずはこのプロジェクトに割り当てられているチームの一覧(リスト)画面が表示されます。

チーム名をクリックして詳細な権限設定に進むと、ベースとなる権限グループ(Read / Write / Maintain / Admin / Custom)が選べるようになります。

プリセットのロールを選ぶだけでも運用はできますが、Custom を選択すると、「このチームにはPlan(計画)の実行だけを許して、Apply(適用)はさせたくない」、「変数の変更はいいけどStateのダウンロードはNG」といった、現場の役割分担に合わせたオーダーメイドの権限設定が作れちゃいます。

💡 ちょっとしたTips:おすすめのカスタム権限の作り方 このカスタム設定、項目が多すぎて「ゼロから全部チェックを入れていくのは大変…」と感じるかもしれません。 そんなときは、まず「Write」や「Maintain」など、作りたい権限に近いプリセットを先に選択してから、「Custom Permissions」から「ここだけチェックを外す」「ここだけ追加する」という調整をするだけで、スムーズに理想の権限セットが作れます。

それでは、画面上で設定できる詳細なカスタム項目について、「具体的にどの区分で、どんな操作がコントロールできるのか」を一覧表にまとめてみました!

現場で「誰にどこまで触らせるか」を設計する際の、頼もしいコントロールパネルの中身をチェックしてみましょう👇

区分 権限 権限の説明 Read Write Maintain Admin
Project access Read プロジェクトの閲覧権限
Update 上記+プロジェクト名の変更権限
Delete 上記+プロジェクトの削除権限
Create workspaces ワークスペースの新規作成権限(すべてのワークスペースの閲覧権限も含む)
Delete workspaces ワークスペースの削除権限
Move workspaces ワークスペースのプロジェクト間の移動権限(移動元/先の両方にこの権限が必要)
Team management None 権限なし
Read プロジェクトに割り当てられたチームの閲覧権限(組織に公開されている場合のみ)。
Manage 既存のチーム権限の変更権限+新しいチーム権限の追加権限
Run access Read 実行に関する一般的な情報(ログ、ポリシーチェック結果、コスト見積もりなど)の閲覧権限
Plan 上記+プラン(Plan)の実行/コメントの追加権限
Apply 上記+実行の適用(Apply)/破棄/キャンセル権限
Variable access No access 権限なし
Read ワークスペースの変数や、適用されている変数セットの閲覧権限
Read and write 上記+ワークスペースの編集権限
Variable set access< No access 権限なし
Read プロジェクト内の変数セットの閲覧権限
Manage 上記+プロジェクト内の変数セットの作成/編集/削除権限。
State access No access 権限なし
Read outputs only Stateバージョンから出力値(Outputs)の閲覧権限
Read ワークスペースのStateバージョンの閲覧権限
Read and write 上記+新しいバージョンの手動作成権限
Other controls Download Sentinel mocks Sentinelのモックデータのダウンロード権限
Manage workspace Run Tasks ワークスペースに対するRun Task(実行タスク)の割り当て/解除権限
Lock/unlock workspaces ワークスペースの手動ロック/ロック解除権限

3.2. Settings / Auto-destroy workspace

プロジェクト設定の中には、検証環境の消し忘れを防ぐ「Auto-destroy(自動破棄)」のメニューも登場します。 こちらは現場の「運用自動化」におけるとても重要な機能なので、今回のツアーでは「ここにメニューがあるんだな」という確認に留め、今後の連載(【第5回】消し忘れよ、さようなら。時間が来たら自動で消える「環境爆破機能」が超便利だった)で実際に環境を爆破させながらガッツリ深掘り検証していきます。どうぞお楽しみに!

3.3. Settings / Notifications

最後に「Notifications(通知)」のメニューです。
画面の見た目やSlack・Teams等と連携できる仕様自体は、先ほどの「組織設定」の画面と大きくは変わりません。ただ、プロジェクトレベルで設定することによって、そのプロジェクト配下にあるすべてのワークスペースに対して、通知ルールを一括適用できます。複数チームでの並行開発時に地味に威力を発揮します。

以上で、プロジェクトレベルでのPremium限定メニューツアーは終了です!

最上位の組織設定に比べるとメニューの数自体は「少数精鋭」でしたが、配下の環境へ通知を一括適用したり、現場の役割に合わせたオーダーメイドの「カスタム権限」を設計したりと、チームで安全にインフラを運用するための重要な土台が集まっていましたね。

さあ、準備は万端です。次はいよいよ最後の階層である「4. 画面ツアー③:【ワークスペース(Workspace)設定】編」へ突入します! 私たちエンジニアが普段一番よく触ることになる、そして一番メニューが激変する「自動化・リスク管理の本命エリア」です。最後まで一気にのぞいていきましょう〜!

4. 画面ツアー③:【ワークスペース(Workspace)設定】編

この章では、現場のエンジニアが日々一番よく触ることになる「ワークスペース(Workspace)」レベルのPremium限定メニューをツアーします。
比較的新しい機能の 「Actions」 や、画面内での回覧板機能である 「Change requests」 、さらにSettings配下のディープなセキュリティ設定( HYOK や詳細な Access )など、Premiumプランの「本命エリア」の見た目をサクッと押さえていきましょう!

4.1. Actions

「4. 画面ツアー③:【ワークスペース(Workspace)設定】編」の最初のメニューは、半年前くらいにGA(一般提供開始)された比較的新しい機能「Actions」です!

この機能は、インフラをコード化して構築(Day 1)するだけでなく、構築した『後』の日常的な運用保守作業(いわゆるDay 2 オペレーション)を効率化・自動化するために生まれました。(参考 HashiCorp のブログ

例えば、現場でよくある以下のような運用ユースケースを想定して作られています👇

  • VM(仮想マシン)をたてた後に、AnsibleのPlaybookを連動して流す
  • 調子が悪いときに、オンデマンドでインフラのヘルスチェックを実行する
  • コスト節約のために、開発環境のサーバーをポチッと起動・停止する

私たちの検証画面を見てみると、スクショのように 「No actions available(利用可能なアクションはありません)」 と表示されていて、今はまだ空っぽの状態です。 これは、具体的にどんなアクションを動かすかを定義したHCL(コード)をまだ用意していないため。しっかりコードを配置して有効化すれば、ここに実行用のダッシュボードが登場する仕組みになっています。

実はこの機能、今回の連載(全6回)の当初のロードマップには入っていませんでした!(笑) ですが、日々のインフラ運用をラクにしてくれそうな、ポテンシャルの高い機能です。

というわけで、本連載とは別に『番外編』として、実際にActionsを定義して動かしてみる検証記事を別途お届けしたいと思います!現場の運用がどう変わるのか、ぜひ番外編も楽しみにしていてくださいね。

4.2. Change requests

続いては「Change requests」のメニューです!

先ほどの「2.2. Explorer」の章で、ワークスペースにチェックを入れて青いボタンをポチッと押す一括作成の導線をご紹介しましたね。 あちらのExplorer画面が「変更要求を新しく出す側の画面」だったのに対し、こちらのワークスペース階層の画面は、「出された変更要求が届き、一覧としてストックされる場所(受ける側)」になります。

私たちの検証画面(スクショ)を見てみると、実際に作成された変更要求(Change request by…)がリストとして1件しっかり届いているのが確認できますね!

このように、個別のワークスペースごとに「今、この環境に対してどんな修正リクエストが来ているのか」や、「過去にどんな修正リクエストが来ていたのか」の履歴がここにすべて集約されます。また、同じ画面上で Plan や Apply を実行できるような画面構成になっています。

外部のチケット管理ツールやチャットツールで「あのワークスペースの設定、ちょっと変えといて〜」と雑に依頼して流れてしまうのを防ぎ、Terraformの画面内に「依頼のメモ」をスマートに残しておける機能として捉えると、非常にしっくりくるメニューです。

4.3. Health

次は「Health」メニューです!

ここは、Premiumプランの目玉機能である「ドリフト検知(実際のクラウド環境とコードのズレの自動チェック)」のステータスを確認できるダッシュボード画面になります。

私たちの検証環境の画面を見てみると、緑色のチェックマークと共に 「No drift detected(ドリフトは検知されませんでした)」 と表示されています。コードと実際のGoogle Cloudの状態が100%一致している健康な状態です。

詳しい検証は、次回【第4回】の連載で「あえてクラウド側を勝手に弄ってドリフト(野良変更)を起こす」という形でガッツリお届けしますので、どうぞお楽しみに!

さて、ここからはルート画面を離れ、本丸である「Settings(設定)」の配下に潜っていきましょう。Premiumならではのメニューが3つ追加されています!

4.4. Settings / HYOK Encryption

ワークスペースの「Settings」配下、最初のメニューは「HYOK Encryption」です。

ここは、「2.7. HYOK Encryption」で組織に登録した独自の暗号化キーを、このワークスペースに対してマッピング(適用)して有効化する画面になります。

画面にある「Enable HYOK on this workspace」のチェックを入れて、「Update setting」ボタンを押してあげるだけで、このワークスペースが扱うStateファイルなどの機密データが、自前のGoogle Cloud KMSのキーで暗号化されるようになります。

組織全体で強制するのではなく、「本番環境などの特にセキュリティをガチガチにしたいワークスペースだけピンポイントで有効化する」といった柔軟な運用ができる画面です。

なお、一度ワークスペースでHYOK Encryptionを有効化すると、後から無効化(オフ)にすることは一切できなくなります!

チェックを入れようとすると、画面のように警告ポップアップが出現します。

4.5. Settings / Health

続いては「Health」の設定画面です。

何度か登場している「ドリフト検知」の機能を、このワークスペース単位で「Enable(有効)」にするか「Disable(無効)」にするかをパチパチと切り替えるだけのシンプルな画面になっています。 実際の動作検証は第4回にたっぷりお届けするので、今回は見た目のチェックだけでOKです!

なお、組織全体でドリフト検知を有効化している場合はこの画面から変更はできません。

4.6. Settings / Access

ワークスペース設定、最後のメニューは「Access」です!

ここでは、この特定のワークスペースに対して「どのチームに、どこまでの操作を許すか」を個別指定できます。

やっていることは「3.1. プロジェクト設定のTeam access」とほぼ同じですが、こちらはワークスペース単位の設定になります。

先ほどのプロジェクト設定の表に載せていた項目のうち、「Run access」以降のより実務的な項目(PlanやApplyの実行可否、変数の読み書き、Stateのダウンロード権限など)を、環境ごとにピンポイントで微調整・上書きできる画面です。 プロジェクト全体のルールよりも「この本番環境だけはさらに厳しく縛りたい!」といった、最後の砦となるアクセス制御がここで完成します。

5. 次回予告

今回の「Premium限定機能ツアー」で、管理画面の全体像や追加メニューの見た目は押さえられましたか?

次回からは、今回ツアーした大物機能たちを環境内で実際に動かしていく実践編に突入します。気になる次回の内容はこちら👇

  • 【第3回】コード書かずにインフラ作れる?「No-Code Provisioning」をポチポチしてみた インフラ知識が浅いメンバーでも、本当に画面ポチポチだけで安全にセルフサービスで環境を作れるのかを実際に検証してみます!

ぜひブックマークして、今後のプラン選びや運用のヒントにしてください。次回の連載もお楽しみに!

「にこぷす通信」について

「NIC × Ops(にこぷす)通信」は、隔週で皆さまに情報をお届けします。
このシリーズでは、Instana(可観測性)をはじめ、Turbonomic(リソース最適化)やTerraform(インフラ自動化)など、IT運用を劇的に変える製品をピックアップしていきます。
これからも最新の技術検証をチームで継続し、皆さまの現場ですぐに役立つ「有益な知見」を全力で共有していきます。 次回の連載もお楽しみに!

ページのトップへ