Page Comparison

List of confidential information to get from Ravi

Adeptia Connect secures your confidential data by keeping it in encrypted form. It extracts your sensitive data such as database username, password, etc. from values.yaml file, and stores it in Secrets. If you're using Vault

that you specify while deploying the application, and stores in values  You need to specify your sensitive data such as database username, password, etc. in the values.yaml fileSecrets in a Microservices architecture is an object that stores confidential information in encrypted form, for example, database credentials, username, passwords, API keys, email addresses, etc. These confidential information may be used for deployment or while using the application. For instance, you need to provide database credentials at the time of deployment to connect to the log and backend databases, and you need to enter your login credentials to log in to the application after deployment.

Adeptia Connect stores such confidential information in encrypted form in Secrets, and offers you the option of using the default Kubernetes Secrets or the one from a third party. The sections below describe how you can use the default Kubernetes Secrets or configure the Secrets provided by a third party, for example, Vault.

Using default Kubernetes Secrets

When you're going to use the default Secrets, you need to pass the confidential information on to the Kubernetes for the creation of Secrets through some properties and environment variables in values.yaml file at the time of deployment. Given below is the list of properties or environment variables that you may need to set.

In env variables enter the followings:

BACKEND_DB_USERNAME:
BACKEND_DB_PASSWORD:

LOG_DB_PASSWORD:
LOG_DB_USERNAME:

LOG_ARCHIVE_DB_PASSWORD:
LOG_ARCHIVE_DB_USERNAME:

In pullSecret.

enabled: true 

registry: repository provided by Adeptia 
username: provided by Adeptia 
password: provided by Adeptia 

For each microservice, provide.

image.repository: to reach to the image, provided by adeptia

image.tag: provided by adeptia

Rest of the settings will remain same.

Using third party tool for secrets

If you wish to use a third party tool such as Vault to manage the Secrets, you may need to do the followings.

• Perform some settings in the tool.
• Set some properties in values.yaml file.

Performing some settings in the tool

To use Vault as a tool for managing Secrets, you need to log in to the tool, and create the followings.

• Secrets – A folder that contains different types of Secrets, having related confidential information, for example, database Secret. You need to have two types of Secrets created in Vault – database Secrets, and Image Secrets. 
  To manage the database Secrets, you need to have the following details in key value pairs. For this, you need to create the following environment variables, and set their values.
  • BACKEND_DB_USERNAME:
  • BACKEND_DB_PASSWORD:
  • LOG_DB_PASSWORD:
  • LOG_DB_USERNAME:
  • LOG_ARCHIVE_DB_PASSWORD:
  • LOG_ARCHIVE_DB_USERNAME:
  In the Image Secrets, you need to have the address of the image repository provided by Adeptia. 
• Policies – Defines the type of permissions – create, read, update, delete, and list – Adeptia Connect may have on Secrets.
• Authentication method – To authenticate the request coming from the Kubernetes host. 
• Roles – Contains the details about the policies created, service account name, and the namespace.

After you've completed the settings in Vault, you need to provide the following information in the values.yaml file.

VAULT_ADDR:   vault url

pullSecret:
enabled: false

secret:
enabled: true
vaultMountPoint: valuelabs-dev authntication method
vaultRole: valuelabs-dev-role role defined in auth mthod
# Data path should be like "kv/data/valuelabs-dev/db-secret"
dbDataFrom: db secret path
# Data path should be like "kv/data/valuelabs-dev/image-secret"
imageDataFrom: image secret path