ModelOp Center seamlessly integrates with existing credential management systems, such as Vault, to allow enterprises to leverage existing IT investments.

Table of Contents

1 Introduction
2 Vault Integration Setup
- 2.1 Prerequisites
  - 2.1.1 Core services
- 2.2 Package Configuration
- 2.3 Vault Client Setup
3 Configuring Credentials for ModelOp Center Core Services
- 3.1 Vault “usage key” per Core Service
  - 3.1.1 Git Credentials from Vault
  - 3.1.2 S3 Credentials from Vault
  - 3.1.3 Mongo Credentials from Vault
  - 3.1.4 Jenkins Credentials from Vault
  - 3.1.5 Jira Credentials from Vault
  - 3.1.6 Service Now Credentials from Vault
  - 3.1.7 Veracode Credentials from Vault
  - 3.1.8 SagerMaker Credentials from Vault
4 Related Articles

Introduction

HashiCorp Vault is a secrets management solution that brokers access for both humans and machines, through programmatic access, to systems. For more details about Vault please visit their website here.

ModelOp Center provides the ability to integrate with Vault to secure the credentials for core ModelOp Center services. It extends the overall credentials framework that supports third party providers to the core ModelOp Center services.

The image above depicts the way ModelOp Center’s credentials framework leverages the Vault integration to retrieve secrets from Vault in order to connect to different core services. The sagemaker-service, not depicted on the diagram, also supports vault credentials.

Vault Integration Setup

Prerequisites

Core services

This guide assumes a basic setup of the core ModelOp Center services has been performed prior to attempt to retrieve the service’s credentials using Vault.

The ModelOp Center services supported for integration with vault are listed below:

Git (via model-manager)
S3 (via model-manager)
MongoDb (via model-manager)
Jenkins (via model-manager)
Jira (via mlc-manager)
Service Now (via mlc-manager)
Veracode (via mlc-manager)
SageMaker Service (via sagemaker-service)

Package Configuration

As per the list above the Vault integration requires the “credentials-vault” jar to be present in the classpath of the model-manager, mlc-manager, and/or sagemaker-service microservices, depending on the core service that it is needed for.

Vault Client Setup

ModelOp Center Vault integration supports token authentication with Vault server.

The Token may be injected as the property (or environment variable) vault.token, or may be passed in a file by providing the file name in the property vault.token_file.
The remote URL to connect to Vault server is provided with the property vault.uri in the form of a fully formed address.
A default path using the environment property vault.defaultPath must be provided to retrieve the keys if no custom mapping is specified.

In general the Vault configuration can look as shown in the example below:

vault:
  token_file: /modelop/vault-token
  uri: https://vault:8200
  defaultPath: secret/data/modelop-services

NOTE: The above will have to be done on model-manager, mlc-manager, and/or sagemaker-service as needed by the core service.

Configuring Credentials for ModelOp Center Core Services

By default, Vault secrets will take precedence over the default Kubernetes secrets approach. In other words, the SpringBoot properties being loaded with secrets as part of property injection in the application are considered part of a core-service key only after looking it up in Vault first. Hence you can potentially store only the passwords on Vault and the users (or other core services usage keys) can be loaded from the properties.

By default, the ModelOp Center integration with Vault will search for specific keys on the configured default path. If it finds a matching key it will try to use the corresponding value in the credentials to connect to the matching core service. Please see each section below for a full list of keys looked up per core service.

Additionally, if the keys found in the Vault secrets are different from the ones expected on the list below, we can provide a list of mappings as part of the properties of the mlc-manager, model-manager, and/or sagemaker-service as in the example below:

vault:
  mappings.1.path: <Vault path of secret>
  mappings.1.vaultKey: <key as found on Vault>
  mappings.1.usageKey: <core service usage key>
  mappings.2.path: <Vault path of secret>
  mappings.2.vaultKey: <key as found on Vault>
  mappings.2.usageKey: <core service usage key>

Example values for the variables above specified between <tags>:

Vault path of secret - As configured on Vault, this is where the secret resides; the host base URI doesn’t need to be included. For example “secret/data/modelop-services”.
Key as found on Vault - If the required key for the core service is not found on Vault, this is the key on Vault we need to map to our core services. For example “JENKINS_PASSWORD”.
Core service usage key - From the sections below, this is what each core service requires as usage key for each of the properties. For example “model-manage.jenkins-credentials.storedCredentials.password”.

NOTE: The mappings list above should continue the number sequence as we add more core services from Vault.

NOTE: The above will have to be done on model-manager, mlc-manager, and/or sagemaker-service as needed by the core service.

Vault “usage key” per Core Service

To fill in on the example above vault.mappings or to configure Vault using only the vault.defaultPath please refer to the usageKeys per core service below.