3.8 Secret management on JP1 Cloud Service/Operations Integration User's Guide

3.8.1 Register a secret

Mon, 01 Jan 0001 00:00:00 +0000

As a prerequisite setting for executing the workflow, it is necessary to register the secret of the environment that is linked to Vault. Playbook is registered in Git, so linking with Git is required. The operation method is as follows, with linking to Git used as an example. Configure other environments that must be linked in the same way. (1) Creating a secrets engine 1. Click "Enable new engines" in the Secrets Engines window of the Secrets tab to go to the Secrets Engines selection window.

3.8.2 Change a secret

Mon, 01 Jan 0001 00:00:00 +0000

The secret can be changed in the following ways. Changing a secret by incrementing the version Deleting and recreating a secret If the secret is changed by incrementing the version, the secret version will be changed. If the secret version is specified in the Workflow YAML file, it must always match the specified secret version. For an example of the Workflow YAML file when specifying the secret version, see “Register user credential information”.

3.8.3 Register user credential information

Mon, 01 Jan 0001 00:00:00 +0000

In the workflow YAML file, if the action label for “Provided Ops I components” is set to “oi.fetch_access_token”, etc., the secret information in which the user’s credential information is stored is listed in the input label. <Example: For oi.fetch_access_token> tasks: # fetch Ops I API access token. fetch_access_token: action: oi.fetch_access_token input: opsi_user_secret_mount_point: secrets/opsi opsi_user_secret_path: /user/credential opsi_user_secret_kv_version: 2 opsi_user_secret_version: "1" next: - when: <% succeeded() %> publish: - opsi_access_token: <% result().output.access_token %> - domain_name: <% result().output.origin %> - when: <% failed() %> do: fail If the secret version is defined in a YAML file, it must always match the specified secret version.