Workflow Automation で外部サービスを操作するとき、API キーの管理に悩んでいませんか？New Relic の Secrets Management Service を使えば、認証情報をワークフロー定義から切り離してセキュアに管理できます。

はじめに

New Relicの Workflow Automation（ワークフロー自動化）、便利ですよね。
AWSのインスタンスを操作したり、Slackにアラート通知を飛ばしたりと様々な自動化が実現できますが、ここで必ずブチ当たるのが 「外部サービスのAPIキーやパスワードをどう管理するか」 という問題です。

「とりあえず直接書いちゃえ！」とハードコードするのは、セキュリティの観点から絶対に NG です。

そこで活用したいのが、New Relic の Secrets Management Service（シークレット管理サービス）。NerdGraph（GraphQL API）を経由してシークレットを一元管理し、Workflow Automation 側からは安全に参照することができます。

本記事では、シークレットの登録・運用手順から、Workflow Automation での具体的な呼び出し方まで、実践的な流れで解説します！

Workflow Automation の利用には Advanced CCU の契約が必要です。

最新のアップデートの詳細はこちら
New Relic アップデート一覧

無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！

1. 始める前の準備（前提条件）

この機能を利用するには、以下の準備が必要です。事前に確認しておきましょう。

New Relic アカウント：Advanced Compute の契約が必要です。
API ユーザーキー：NerdGraphを叩くための User API Key（Mutation権限を持つもの）を用意します。
適切な権限(ロール)：
- Organization Manager：すべてのシークレットの作成・管理・完全削除が可能です。
- Standard User / All Product Admin：所属アカウント内のシークレット作成や、共有可能シークレットの作成が可能です。

カスタムロールを使用している場合は、Secret Management 関連の権限が付与されているか管理者へ確認してください。

Organization Role

Accounts Role

登録作業はすべて NerdGraph APIを使用するため、NerdGraph API Explorer（one.newrelic.com > All capabilities > Apps > NerdGraph API explorer）から行います。

2. 【実践】NerdGraphでシークレットを登録する

アカウント内の権限を持つユーザーやプロセスであれば、誰でもアクセスできる標準的なシークレットです。

mutation {
  secretsManagementCreateSecret(
    scope: { type: ACCOUNT, id: "YOUR_NR_ACCOUNT_ID" }
    namespace: "aws"
    key: "awsAccessKeyId"
    description: "AWS Access Key ID for workflow automation"
    value: "YOUR_AWS_ACCESS_KEY_ID"
  ) {
    key
    latestVersion
    scope { type id }
  }
}

パラメータのポイント:

scope.type: ACCOUNT（単一アカウント）または ORGANIZATION（組織全体）を指定します。
namespace: シークレットを論理グループ化する名前（例: aws, slack）。管理しやすくなるため、設定を強く推奨します。
key: ネームスペース内で一意となるシークレットの識別子です。
value: 実際の機密情報（API キーやパスワードなど）を入力します。

登録作業はすべて NerdGraph Explorer（one.newrelic.com > All Capabilities > Query your data > NerdGraph）から行います。

3. シークレットの確認・運用（参照、更新、削除）

登録したシークレットを管理するための、よく使うクエリ・ミューテーション集です。

3.1 値が正しく登録されているか確認する（復号）

unlock: true を明示的に指定することで、暗号化されている実際の値を確認できます。

{
  customerAdministration {
    secret(
      key: "awsAccessKeyId"
      namespace: "aws"
      scope: { id: "YOUR_NR_ACCOUNT_ID", type: ACCOUNT }
      unlock: true
    ) {
      key
      namespace
      retrievedValue { value version }
    }
  }
}

3.2 一覧とバージョン履歴の確認

「どんなシークレットがあるか」「過去に何回更新されたか（最大10バージョン保持）」を確認します。

シークレット一覧の取得

{
  customerAdministration {
    secrets(
      filter: { deleted: { eq: false }, scope: { eq: { id: "YOUR_NR_ACCOUNT_ID", type: ACCOUNT } } }
      sort: { direction: DESC, key: CREATED_AT }
    ) {
      totalCount
      secrets { key namespace description latestVersion }
    }
  }
}

バージョン履歴の確認

{
  customerAdministration {
    secretVersions(
      key: "awsAccessKeyId"
      namespace: "aws"
      scope: { id: "YOUR_NR_ACCOUNT_ID", type: ACCOUNT }
      fetchDeleted: false
    ) {
      key
      secretVersions { version createdAt isDeleted }
    }
  }
}

3.3 更新と削除（論理削除・物理削除）

定期的なキー変更や、不要になった際の削除手順です。削除には、後から復元できる 「論理削除」 と、完全に消去する 「物理削除」 の2種類がある点に注意してください。

値の更新（自動的に新しいバージョンが作られます）

mutation {
  secretsManagementUpdateSecret(
    key: "awsAccessKeyId"
    namespace: "aws"
    scope: { id: "YOUR_NR_ACCOUNT_ID", type: ACCOUNT }
    value: "NEW_AWS_ACCESS_KEY_ID"
  ) { key latestVersion }
}

1. 論理削除（一時削除：後から復元可能なので普段はこちらを推奨）

mutation {
  secretsManagementDeleteSecret(
    key: "awsAccessKeyId"
    namespace: "aws"
    scope: { id: "YOUR_NR_ACCOUNT_ID", type: ACCOUNT }
    purge: false
  ) { key namespace }
}

2. 物理削除（完全削除：復元不可・製品管理者のみ実行可能）

mutation {
  secretsManagementDeleteSecret(
    key: "awsAccessKeyId"
    namespace: "aws"
    scope: { id: "YOUR_NR_ACCOUNT_ID", type: ACCOUNT }
    purge: true
  ) { key namespace }
}

間違えて論理削除しちゃった時は？
secretsManagementRecoverSecret ミューテーションを実行すれば、元の状態に復元可能です！

4. Workflow Automation でシークレットを呼び出す

いよいよ本題です。登録したシークレットをワークフロー定義（YAML等）の中で使う場合の構文と具体例です。

4.1 参照のための基本構文

ネームスペースなし: ${{ :secrets:KEY_NAME }}
ネームスペースあり: ${{ :secrets:NAMESPACE:KEY_NAME }}

GUI で設定する場合は、入力補完に対応しています。${{ を入力すると設定可能な候補がリストで選択可能です。

4.2 ワークフロー定義での実践例

例①：AWS の認証情報を使って EC2 を操作する

aws というネームスペースに隠した認証情報を、以下のようにスマートに呼び出せます。

steps:
  - name: resizeEC2Instance
    type: action
    action: aws.execute.api
    version: 1
    inputs:
      service: ec2
      api: modify_instance_attribute
      credentials:
        # シークレットマネージャーから安全にマッピング
        awsAccessKeyId: "${{ :secrets:aws:awsAccessKeyId }}"
        awsSecretAccessKey: "${{ :secrets:aws:awsSecretAccessKey }}"
        awsRegion: "${{ .workflowInputs.awsRegion }}"
      parameters:
        InstanceId: "${{ .workflowInputs.instanceId }}"
        InstanceType: "${{ .workflowInputs.instanceType }}"

例②：Slack 通知で Bot トークンを使う

チャンネル通知用のトークンも、ハードコードせずにネームスペース指定で参照します。

steps:
  - name: sendSlackAlert
    type: action
    action: slack.sendMessage
    version: 1
    inputs:
      # slack ネームスペースから安全に取得
      token: "${{ :secrets:slack:botToken }}"
      channel: "#ops-alerts"
      text: "Alert: ${{ .workflowInputs.alertMessage }}"

5. 運用で泣かないためのセキュリティベストプラクティス

最後に、本番運用で意識しておきたい4つの防衛策をまとめます。

「アクセスキー」から「IAMロール」へのシフト
AWS等の操作では、可能であれば永続的なアクセスキーを発行・登録するのではなく、自動ローテーションされるIAMロール（一時資格情報）が使えないか検討しましょう。
最低90日でのローテーション
アクセスキー形式のシークレットを使う場合は、最大でも90日サイクルでキーを更新する運用ルールを作りましょう。
本番環境とテスト環境の「完全分離」
ネームスペースを活用し、prod_slack:botToken と stg_slack:botToken のように明確に分けてシークレットを登録し、誤操作を防ぎましょう。
フリーテキスト欄への機密情報混入に注意
ワークフロー定義の name や description などのフィールドに、うっかりパスワードなどの文字列を直書きしないようレビューを徹底してください。

まとめ

New Relic の Secrets Management Service を導入することで、「便利だけどセキュリティが心配…」という自動化ワークフローの課題を一発でクリアできます。NerdGraphの操作に少し慣れが必要ですが、一度組んでしまえばセキュアで強固な運用が可能になります。ぜひ試してみてください！

New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！

New Relic株式会社のX(旧Twitter) や Qiita Organizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。

無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！