Workflow Automation に API キーをハードコードしていませんか？New Relic シークレット管理サービス実践ガイド

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つの防衛策をまとめます。

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

まとめ

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

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

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

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