call
Go to Console

 

Database Console Guide

 

This page provides a clear and complete guide to the Database section of the Namirasoft Credential Console. The Database credential type is generic: it stores the connection details needed to reach almost any database engine, including host, port, authentication, SSL configuration, and an optional SSH tunnel. Use this guide to understand each field and configure secure database access for your Namirasoft applications.

 

What Is the Database Credential?

A Database credential stores everything Namirasoft needs to connect to a database on your behalf. Because the core connection fields (host, port, username, password, and SSL) are standard across most database engines, a single Database credential type can connect to many different systems without requiring a separate credential type for each one.

 

This means any database that exposes a host, port, and login, or a full connection string, can be registered here, not only the examples shown in the section below.

 

Why Secure Database Credential Management Matters

A database often contains essential operational and business data. Applications require authorized access to retrieve, insert, or update this data during runtime. Storing connection details manually inside application code, configuration files, or environment variables increases the risk of:

 

  • Accidental credential exposure in logs or repositories

 

  • Connecting to the wrong environment, such as production instead of staging

 

  • Loss of control when credentials are shared across multiple services

 

  • Lack of rotation or auditing when access needs to change

 

Without proper storage practices, these vulnerabilities can lead to data exposure or system compromise.

 

Overview of Database Fields and Options

The sections below explain each field in the Database credential form. Understanding these fields will help you define connection parameters correctly, validate access, and link your database to Namirasoft services with full clarity and control.

 

  • ID (String): This is the unique identifier automatically generated by Namirasoft Credential when the database credential is created. You do not enter or modify this value. It is used internally for tracking, linking, and referencing the entry across the Namirasoft ecosystem.

 

  • User ID (Namirasoft Account’s ID): This is the unique ID assigned to the Namirasoft Account that created the credential. It serves as a link between the credential and the user who owns or manages it.

 

  • Workspace ID (Namirasoft Workspace’s ID): This refers to a workspace created in the Namirasoft Workspace app, which allows users to organize credentials by project, environment, or team. The workspace name is displayed along with the ID, and it links back to the Namirasoft Workspace app where the workspace details can be viewed.

 

  • Name (String): This is a human friendly label you choose to identify the credential, such as Production Database or Reporting Server. It helps you and your team recognize which connection is which and has no impact on authentication itself.

 

  • SSH (Enum): This selects the SSH credential to use when the database is hosted inside a private network and cannot be reached directly. When set, Namirasoft connects through a secure SSH tunnel before opening the database connection. For details on setting up SSH credentials, see the SSH Console Guide.

 

  • Type (Enum): The type selects which database engine Namirasoft connects to, so it can use the correct protocol and defaults. The connection fields below are the same for every engine; only the values you enter, and how you obtain them, differ. Choose the engine that matches your server:

 

  • MySQL is a widely used open source relational database that stores data in tables and is queried with SQL (mysql.com).
  • Postgres is a standards compliant open source relational database known for advanced features such as JSON support and full text search (postgresql.org).
  • Mongo is an open source document database that stores JSON like documents in collections (mongodb.com).
  • Elasticsearch is an open source search and analytics engine that stores JSON documents in indices (elastic.co).
  • Clickhouse is an open source columnar database built for fast analytics over large datasets (clickhouse.com).

 

  • Host (String): The host is the network address of the database server, which you enter as a public IP address, private IP address, or domain name. This value is the same for every engine.

 

How to Get Your Host?
  1. Managed or cloud: Open your provider’s dashboard and copy the host, hostname, endpoint, or server value from the connection details, without the port or protocol.
  2. Self hosted: Use the server’s domain name or IP address. If you are not sure which address to use, ask your database administrator.

 

 

  • Port (Integer): The port is the numbered network channel that the server listens on, written after the host address (for example, host:port). Each engine has a default port, but your server may be set to a different one. Use the steps for your engine to confirm the correct value.

 

MySQL
  1. Default: MySQL uses port 3306.
  2. Managed or cloud: Open your provider’s dashboard and read the port from the connection details.
  3. Self hosted: Connect with the MySQL client and run SHOW VARIABLES LIKE 'port';, or check the port value in the my.cnf or my.ini file.

 

 

Postgres
  1. Default: Postgres uses port 5432.
  2. Managed or cloud: Read the port from the connection details in your provider’s dashboard.
  3. Self hosted: Run SHOW port; in psql, or check the port value in the postgresql.conf file.

 

 

Mongo
  1. Default: Mongo uses port 27017.
  2. Managed or cloud (Atlas): Open your cluster in Atlas and read the port from the connection string shown in the dashboard.
  3. Self hosted: Check the net.port value in the mongod.conf file, or run db.serverCmdLineOpts() in mongosh.

 

 

Elasticsearch
  1. Default: Elasticsearch uses port 9200, usually over HTTPS.
  2. Managed or cloud (Elastic Cloud): Find the endpoint and port in your deployment’s connection details.
  3. Self hosted: Check the http.port value in the elasticsearch.yml file.

 

 

Clickhouse
  1. Default: Clickhouse uses 9000 for the native protocol and 8123 for HTTP. Choose the one that matches how your client connects.
  2. Managed or cloud: Read the port from the connection details in your provider’s dashboard.
  3. Self hosted: Check the <tcp_port> (9000) and <http_port> (8123) values in the config.xml file.

 

 

  • Database Name (String): The database name identifies the specific database, also called a schema, that Namirasoft should connect to. A single server can host many databases, so this value selects the correct one. How you find it depends on your engine:

 

MySQL
  1. Connect with the MySQL client, using a terminal or the SQL query tab in MySQL Workbench, and run SHOW DATABASES; to list the available databases.
  2. On a managed or cloud database, the database name also appears in your provider’s connection details. Choose the one your application uses.

 

 

Postgres
  1. Connect with psql and run \l, or SELECT datname FROM pg_database;, to list the available databases.
  2. On a managed or cloud database, the database name also appears in the connection details. Choose the one your application uses.

 

 

Mongo
  1. Open mongosh and run show dbs to list the available databases, then choose the one your application uses.
  2. If your user was created in a different database, which is often admin, note that Parameters mode has no separate authSource field. In that case, use the Connection String and add ?authSource=admin.

 

 

Elasticsearch
  1. Elasticsearch stores data in indices rather than databases, so you can usually leave this field blank.
  2. To view your indices, run GET /_cat/indices in Kibana Dev Tools or with curl. Set this field only if your setup expects a default index.

 

 

Clickhouse
  1. Connect with clickhouse-client and run SHOW DATABASES; to list the available databases. A new installation includes one named default.

 

 

  • Username (String): The username is the account that Namirasoft signs in with. It must have permission to read from, and where required write to, your database. How you obtain it depends on your engine:

 

MySQL
  1. Managed or cloud: The primary user appears in your provider’s dashboard, where you can also create additional users.
  2. Self hosted: Connect as an administrator with mysql -u root -p, then list the existing accounts with SELECT user, host FROM mysql.user;.
  3. To create a dedicated account with least privilege access, run CREATE USER 'namirasoft'@'%' IDENTIFIED BY 'your_password';, then grant only the access it needs, for example GRANT SELECT, INSERT, UPDATE ON your_database.* TO 'namirasoft'@'%'; FLUSH PRIVILEGES;.

 

 

Postgres
  1. Managed or cloud: The primary role appears in your provider’s dashboard.
  2. Self hosted: Connect as the superuser with psql -U postgres, then list the existing roles with \du.
  3. To create a dedicated role with least privilege access, run CREATE ROLE namirasoft WITH LOGIN PASSWORD 'your_password';, then run GRANT CONNECT ON DATABASE your_database TO namirasoft; and grant the specific table privileges it needs.

 

 

Mongo
  1. Managed or cloud (Atlas): Create or view database users under Database Access.
  2. Self hosted: Open mongosh as an administrator with mongosh -u adminUser -p, switch to the admin database with use admin, and list the existing users with db.getUsers().
  3. To create a dedicated user, run db.createUser({ user: "namirasoft", pwd: "your_password", roles: [{ role: "readWrite", db: "your_database" }] }).

 

 

Elasticsearch
  1. A new cluster includes a built in superuser named elastic. For everyday use, create a user with limited permissions instead.
  2. Managed or cloud (Elastic Cloud): Manage users in Kibana under Stack Management → Security → Users.
  3. Self hosted: Create a user through the API by sending POST /_security/user/namirasoft with a password and roles.

 

 

Clickhouse
  1. Connect with clickhouse-client and list the existing accounts with SELECT name FROM system.users;.
  2. To create a dedicated account with least privilege access, run CREATE USER namirasoft IDENTIFIED WITH sha256_password BY 'your_password';, then run GRANT SELECT, INSERT ON your_database.* TO namirasoft;.
  3. If the account is defined in the server configuration instead, its username is stored in users.xml, or in a file under users.d/. Ask whoever set up the server.

 

 

  • Password (String): The password is the secret that pairs with the username above. For every engine, enter the password that was set when the account was created, and reset it only if you do not know it or have lost it.

 

MySQL
  1. MySQL stores the password as a hash, so it cannot be read back.
  2. Self hosted: Reset it by connecting as an administrator and running ALTER USER 'namirasoft'@'%' IDENTIFIED BY 'new_password';.
  3. Managed or cloud: Reset it from your provider’s dashboard.

 

 

Postgres
  1. Postgres does not allow the password to be read back.
  2. Self hosted: Reset it by running ALTER ROLE namirasoft WITH PASSWORD 'new_password';.
  3. Managed or cloud: Reset it from your provider’s dashboard.

 

 

Mongo
  1. MongoDB does not allow the password to be read back.
  2. Self hosted: Reset it by running db.changeUserPassword("namirasoft", "new_password") in mongosh.
  3. Managed or cloud (Atlas): Reset it under Database Access.

 

 

Elasticsearch
  1. If you do not have the elastic user’s password, reset it on the server by running bin/elasticsearch-reset-password -u elastic.
  2. For any other user, reset the password by running bin/elasticsearch-reset-password -u namirasoft, or by sending POST /_security/user/namirasoft/_password. You can verify it with curl -u namirasoft:your_password https://your_host:9200.

 

 

Clickhouse
  1. Self hosted: Reset the password by running ALTER USER namirasoft IDENTIFIED BY 'new_password';.
  2. If the account is defined in the server configuration, its password is stored in users.xml, or in a file under users.d/. Ask whoever set up the server.

 

 

  • Connection String (String): The connection string packs the host, port, database, and credentials into a single URI, which you can use instead of the separate fields above. Your provider often supplies a ready made one; otherwise, assemble it from the values above. The format depends on your engine:

 

Engine Connection String Format
MySQL mysql://username:password@host:3306/database_name
Postgres postgresql://username:password@host:5432/database_name
Mongo mongodb://username:password@host:27017/database_name?authSource=admin
Elasticsearch https://username:password@host:9200
Clickhouse clickhouse://username:password@host:9000/database_name (native)
http://username:password@host:8123/database_name (HTTP)

 

  • Enable SSL (Checkbox): This enables encrypted communication between Namirasoft and the database server, protecting data in transit. Enable this option if your database requires or recommends SSL/TLS connections.

 

  • CA (String): This is the Certificate Authority certificate used to verify the database server’s identity when SSL is enabled. It lets Namirasoft confirm it is connecting to the correct and trusted server, preventing man-in-the-middle attacks.

 

How to Get Your SSL CA Certificate?
  • The CA certificate lets Namirasoft verify it is connecting to the genuine database server
  • On a managed or cloud database, open the provider’s Security or TLS settings and download the CA certificate
  • On a self hosted database, copy the CA file from your engine’s SSL configuration. Common locations:

 

  • MySQL or MariaDB: ca.pem in the data directory (often /var/lib/mysql/)
  • PostgreSQL: the file set by ssl_ca_file in postgresql.conf (often root.crt)
  • ClickHouse: the path set in /etc/clickhouse-server/config.xml
  • MongoDB: download the CA bundle from your provider, or the file set by tlsCAFile

 

  • For any other engine, get the CA the same way from your provider’s TLS settings or your server’s SSL config, then paste its contents here

 

 

  • Cert (String): This is the client certificate presented to the database server when mutual TLS authentication is required. It identifies Namirasoft to the server as a trusted client.

 

How to Get Your SSL Client Certificate?
  • This is needed only when your database requires mutual TLS, where the server also verifies the client
  • On a managed or cloud database, download or generate the client certificate from the provider’s Security or TLS settings
  • On a self hosted database, use the client certificate created when you set up mutual TLS for your engine
  • Paste the certificate contents exactly, or leave it empty if your database does not require mutual TLS

 

 

  • Key (String): This is the private key associated with the client certificate. It completes the SSL handshake when mutual TLS is enabled.

 

How to Get Your SSL Client Key?
  • This is the private key paired with the client certificate above, used for mutual TLS
  • Get it from the same place as the client certificate, your provider TLS settings or your mutual TLS setup
  • Paste the key contents exactly and keep it secret, or leave it empty if mutual TLS is not required

 

 

  • Description (String): This is an optional text field where you can document the purpose or environment of the credential, such as analytics database or staging access. Adding a description is helpful when working with multiple credentials in a shared workspace.

 

  • Created At (DateTime): This shows the exact date and time when the database credential was first created. This value is automatically set when you create the record and does not change over time.

 

  • Updated At (DateTime): This shows the exact date and time when the database credential was most recently modified. It helps you track when the credential was last maintained.

 

Ready to Get Started or Want to Explore the Console Guide?

Get Started Explore Console Guide