• 1. Description
• 2. Development Enviroment
• 2.1 Development API
• 3. Production Enviroment
• 3.1 Production API
• 4. Additional Notes

1. Description

Automation Hub can export all credentials to a SecHub instance, and also import them into a new instance of Automation Hub.

There are two environments, and they are separated in order to prevent development credentials being loaded into a production system.

2. Development Enviroment

In a development workspace, such as gitpod, the credentials are scoped to the user that has logged into the BuildOne UI. The sechub instance used in gitpod workspaces is https://secureable-dev.demo.build.one (defined by the env var AUTHENTICATION_URI)

The workflow is

1. login as axadmin@secureable
2. import the credentials by pressing the “import” button in the AutomationHub UI
3. log out
4. login as your username

At this point, the “development” credentials from axadmin are loaded into AutomationHub.

The secret path in development mode defaults to /automationHub/devWorkspace/<username> unless a path:<path> key is passed in post (See api)

2.1 Development API

There are two api endpoints to export and import AutomationHub credentials into or out of SecHub. Every request must have a header with the jwt obtained when logging into Swat. This is not the same as the sechub token -H "authorization: bearer <jwt>”

Export

A POST to service/automation/api/credentials/export-to-sechub with a body of:

Copy

 {path?:string, token:<sechub token>}

Where SecHub token is the SecHub token obtained when logging in

Import

A POST to service/automation/api/credentials/import-from-sechub with a body of

Copy

 {path?:string, token:<sechub token>}

Where SecHub token is the SecHub token obtained when logging in

3. Production Enviroment

In a production instance, the credentials are scoped to a fixed key, called “deploy”. This is because we do not want to import workspace / test credential & values into a production system. The SecHub instance used is https://secureable-dev.demo.build.one (defined by the env var AUTHENTICATION_URI) The workflow is

1. login as <user>
2. import the credentials by pressing the “import” button in the AutomationHub UI


Warning

This should only be used understanding that importing credentials will overwrite any existing credentials (This could be critical on a production instance)

At this point, the “production” credentials from axadmin are loaded into AutomationHub.

The secret path in production mode defaults to “/automationHub/deploy” unless a path:<path> key is passed in post (see api)

3.1 Production API

There are two api endpoints to export and import AutomationHub credentials into or out of SecHub. Every request must have a header with the jwt obtained when logging into Swat. This is not the same as the sechub token -H "authorization: bearer <jwt>”

Export

A POST to service/automation/api/credentials/export-to-sechub with a body of

Copy

 {path?:string, token:<sechub token>}

Where SecHub token is the SecHub token obtained when logging in

Import

A POST to service/automation/api/credentials/import-from-sechub with a body of

Copy

 {path?:string, token:<sechub token>}

Where SecHub token is the SecHub token obtained when logging in

Default paths

If path is not specified it will default to

• /automationHub//{B1_CREDENTIALS_PATH} if "B1_CREDENTIALS_PATH" is set in the stack env
• /automationHub/deploy if B1_CREDENTIALS_PATH is not set

4. Additional Notes

• It must be noted that when importing into a production system, the path is not the same as a workspace. So if user axadmin exports credentials from a workspace, these credentials are not imported when importing into a production system.
• The UI buttons for import / export use the default path for the environment. You can make a manual curl call to the api specifying the path, however, given the potential for destroying existing production credentials this is not recommended.

Back to Documentation

Back to Home Page