Skip to main content
Version: 11

Version 11 Deployment Process

This document outlines the essential preparation steps required before deploying the Open iT Server and its components. While automation is the long-term goal, many steps in the current process involve careful manual configuration to ensure precision, security, and flexibility during setup.

Although some steps require close attention and manual effort, this guide is designed to make the process as straightforward and consistent as possible. However, please use this document with caution — it is continuously refined to accommodate process improvements, configuration changes, and automation updates.

This guide is primarily intended for DevOps engineers or technical team members familiar with cloud infrastructure and deployment workflows. If you're following this document and not part of the DevOps team, it's highly recommended to coordinate with them to ensure proper setup and configuration.

In addition to serving as a deployment guide, this document can be used as a reference for troubleshooting issues across both manual and automated components.

Requirements​

User and Role Provisioning for Deployment​

Before services can interact with AWS programmatically, you need to create an IAM (Identity and Access Management) user with appropriate permissions. This user will represent your application or deployment tools and will be used to generate access key and secret key — credentials required for secure API access to AWS services like S3, Athena, Glue, or EKS.

This section guides you through creating an IAM user, assigning necessary permissions, and securely generating access credentials. These credentials will later be used by tools such as Terraform, Cube Cloud, or External Secrets Operator to authenticate and perform operations in your AWS account.

Creating IAM Role with Admin Access​

In this section, you will create a dedicated IAM role that holds administrative privileges, which can later be assumed securely by the IAM user. To create an IAM role with admin access:

  1. In the AWS Console, go to IAM > Role.

  2. Click Create Role.

  3. In the Trusted Entity Type panel, select AWS Account. Click Next.

  4. In the Permissions policies, add the AdministratorAccess policy by ticking the checkbox beside the policy name. Click Next.

  5. Fill in the role details fields.

  6. Review trusted entities and added permission. Once verified, click the Create role button.

  7. Once created, click the role and copy the Role ARN (Amazon Resource Name) shown at the top.

    Role ARN Example
    arn:aws:iam::522814696825:role/dev-aws-cli
    tip

    You will need this value in creating a policy and configuring local AWS CLI.

Creating Policy to Assume the Role​

This policy allows your IAM user (used for CLI operations) to assume a role within admin privileges via the AWS CLI. To create the policy:

  1. In the AWS Console, go to IAM > Role.

  2. Click Create Policy.

  3. Go to the JSON tab.

  4. Paste the following JSON policy, then update the Resource ARN to match the role you created.

    Policy Document
    {
    "Version": "2012-10-17",
    "Statement": [
        {
        "Sid": "AllowAssumeAdminRoleWithMFA",
        "Effect": "Allow",
        "Action": [
            "sts:AssumeRole"
        ],
        "Resource": "arn:aws:iam::522814696825:role/dev-aws-cli",
        "Condition": {
            "Bool": {
            "aws:MultiFactorAuthPresent": "true"
            }
          }
        }
      ]
    }

    where:

    ParameterDescription
    sts:AssumeRoleThis action allows the user to switch into another IAM role.
    ResourceThe ARN of the IAM Role you created in previous section (Creating IAM Role with Admin Access)
    ConditionEnsures that the role can only be assumed if Multi-Factor Authentication (MFA) is enabled for the user.
    JSON Policy Document Values

  5. Click Next.

  6. Click Create Policy.

Creating IAM User​

This section focuses on creating a secure IAM user that has permissions to assume the admin role created earlier. To create IAM user:

  1. In the AWS Console, go to IAM > User.

  2. Click Create user button, then:
    a. Configure the user's details.
    b. You can opt to leave Provide user access to the AWS Management Console unchecked.

  3. In the Set Permissions step, click the Create Group button which is in Get started with groups panel.
    a. Fill in the User group Name field.
    b. Tick the checkbox beside the policy you have created from the previous section.
    c. Once set, click the Create user group button, then click the Next button.

  4. Review the user’s name and permissions. Once confirmed, click the Create user button.

Generating Access Keys​

Once you have created the IAM user for CLI operations, you’ll need to generate an access key. This key is essential for programmatic access through AWS CLI and for assuming the role securely. To generate access keys:

  1. In the AWS Console, go to IAM > User.

  2. Go to the Security credentials tab.

  3. Navigate to Access Keys section, then click Create access key.

  4. Choose Command Line Interface (CLI) as the intended use, then click Next.

  5. Once the key is generated, AWS will present the following:

    ParameterDescription
    Access Key IDA publicly identifiable string that represents your IAM user.
    Secret Access KeyA secret string used to verify the identity of the IAM user.
    AWS Keys

    You may click Download .csv to securely store the key file. Alternatively, you may copy and paste the credentials into a secure location such as password managers or encrypted notes.

    warning

    Do not store them in plain text documents or emails.

Updating the Trust Relationship on the IAM Role​

A trust relationship is a policy document attached to an IAM role that defines which users or entities are allowed to assume the role, and under what conditions. To update the trust relationship:

  1. In the AWS Console, go to IAM > Role.

  2. Find and select the IAM role you have created earlier (from Creating IAM Role with Admin Access).

  3. Open the Trust Relationships tab, then click Edit trust policy.

  4. Update the existing JSON by entering the Principal ARN of the User you have created. Below shows the sample updated Trust Relationship:

    Policy Document
    {
    "Version": "2012-10-17",
    "Statement": [
        {
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::522814696825:user/aws-cli"
        },
        "Action": "sts:AssumeRole",
        "Condition": {
            "StringEquals": {
            "aws:PrincipalOrgID": "o-she9go6m6l"
            }
          }
        }
      ]
    }

    where:

    ParameterDescription
    PrincipalThis specifies who is allowed to assume the role. In this case, it's the ARN of the created IAM user.
    "Action": "sts:AssumeRole"The permitted action is sts:AssumeRole, which allows the user to temporarily assume this role.
    "aws:PrincipalOrgID": "o-she9go6m6l"The orgID of Open iT.
    JSON Policy Document Values

  5. Once done, click the Update Policy button to save the changes.

Configuring the Default CLI Profile​

To interact with AWS services from your local machine or automation tools, you need to configure the AWS Command Line Interface (CLI) with valid credentials. Once configured, the AWS CLI can be used to manage cloud resources, test permissions, and support infrastructure automation.

  1. To verify if AWS CLI is properly installed, open your terminal and run the command:

    aws --version

    If not, you may follow the instructions in AWS CLI Installation Guide to install it.

  2. Open your AWS CLI, and run:

    aws configure

  3. Provide the values when prompted:

    • AWS Access Key ID - This is your public identifier for an IAM user.
    • AWS Secret Key - This is your private key used to securely sign requests.
    • Default region name - This tells the AWS CLI which region to use for operations (e.g., us-east-1). You may check the available regions here.
    • Default output format (optional) - This controls how AWS CLI displays command results (e.g., json, yaml, or table).

    Example
    AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
    AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
    Default region name [None]: ap-southeast-1
    Default output format [None]: json

    The values will be stored in:

    ValuesUnixWindows
    Keys~/.aws/credentialsC:\Users\<YourUsername>\.aws\credentials
    Region and output format~/.aws/configC:\Users\<YourUsername>\.aws\config
    AWS Credentials and Configuration Location

  4. To review your credentials, run the command:

    ~/.aws/credentials

Adding the assume-role Profile​

Once your IAM user and IAM role have been correctly configured, create a new AWS CLI profile named assume-role that uses temporary credentials obtained by assuming the admin role. Terraform will use this assume-role profile during execution. To add the assume-role profile:

  1. Open your AWS CLI, run the command:

    Example Command
    aws sts assume-role \ --role-arn arn:aws:iam::522814696825:role/dev-aws-cli \ --role-session-name Dev-CLI \ --duration-seconds 14400

    where:

    ParameterDescription
    awsBase command to access AWS services via terminal.
    stsAWS Security Token Service; Service for temporary; limited privilege credentials.
    assume-roleSTS action that allows a user to assume an IAM role.
    --role-arnAmazon Resource Name of the IAM role to assume.
    --role-session-nameA unique identifier for the assumed session.
    --duration-secondsThe duration of the session in seconds.
    Assume Role Parameters

    In the example, the command requests temporary security credentials from AWS STS by assuming the specified IAM role (dev-aws-cli) for a session named Dev-CLI, valid for 4 hours (14,400 seconds).

  2. Copy the returned temporary credentials. The output will look like this:

    Assume Role Output
    {
    "Credentials": {
        "AccessKeyId": "ASIAxxxxxxxxxxxx",
        "SecretAccessKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "SessionToken": "xxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "Expiration": "2025-06-05T12:34:56Z"
        }
    }

    Use these three values to define the assume-role profile.

  3. Update your AWS CLI configuration file, run the command:

    code ~/.aws/credentials

  4. Update the file as follows:

    AWS Credentials
    [default]
    aws_access_key_id = YOUR_STATIC_USER_ACCESS_KEY
    aws_secret_access_key = YOUR_STATIC_USER_SECRET_KEY

    [assume-role]
    aws_access_key_id = ASIAxxxxxxxxxxxx
    aws_secret_access_key = xxxxxxxxxxxxxxxxxxxxxxxxxxx
    aws_session_token = xxxxxxxxxxxxxxxxxxxxxxxxxxx

    where:

    ParameterDescription
    [default]The profile that contains your IAM user’s long-lived credentials.
    [assume-role]The profile that contains the temporary credentials from the sts assume-role command. Terraform will use this profile.
    AWS Credentials

  5. To verify, run the command:

    aws sts get-caller-identity --profile assume-role

    The output should display that you are operating under the assumed role:

    Example
    "Arn": "arn:aws:sts::522814696825:assumed-role/dev-aws-cli/Dev-CLI"

Setting Up S3 as a Remote Backend for tfstate​

To configure a remote backend for Terraform state management, you’ll need to create an S3 bucket that will store the tfstate files used during deployment.

  1. Go to Amazon S3 in the AWS Console.

  2. Under General purpose buckets, click Create bucket.

  3. Provide a unique and clearly labeled bucket name — ideally one that includes a warning like do-not-delete (e.g., openit-tfstate-do-not-delete). You may also refer to the General Purpose Buckets Naming Rules for additional guidelines.

    warning

    This S3 bucket keeps track of everything Terraform builds. If you delete it without first cleaning up the infrastructure, Terraform can "forget" what it created — which might lead to things getting out of sync or stuck in the cloud with no easy way to manage or remove them.

  4. Click Create bucket.

  5. Take note of the bucket name and AWS region. These details will be required later in the Deployment Orchestrator.

    note

    You only need to do this once per tenant.

Creating a Hosted Zone for a Subdomain in Route 53​

  1. In the AWS Route 53 Console, go to Route53.

  2. Click the Hosted zones, then select Create hosted zone.

  3. Enter the Subdomain Name. In the Domain name field, enter your subdomain. Since you don't own the parent domain (openit.cloud or openitdev.com) in your current AWS tenant, you can create a subdomain like internal.openit.cloud or sample.openit.cloud.

  4. Add a Description. This is optional.

  5. Set Type to Public Hosted Zone. This ensures the DNS records will be publicly resolvable.

  6. Click Create hosted zone.

  7. Once the hosted zone is created, it will appear in the Records table. Locate the NS (Name Server) record—this contains the Value/Route traffic to field, which lists the name servers assigned to your new subdomain. Share these name server values with the owner of the parent domain (e.g., openit.cloud or openitdev.com) and request that they create a corresponding NS record in their hosted zone. This step delegates control of the subdomain (e.g., sample.openit.cloud) to your newly created hosted zone.

Retrieving Route 53 Zone Information​

  1. In the AWS Route 53 Console, go to Route 53.

  2. Click the Hosted zones in the sidebar.

  3. Select the hosted zone associated with your domain.

  4. In the Hosted Zone details panel, look for the Hosted Zone ID.

    note

    This value uniquely identifies the hosted zone in AWS Route 53. Terraform uses this ID to create DNS records within the specified zone.

Registering Open iT Application on Azure Portal​

This section explains how to register an application in the Azure Portal to enable OpenID Connect (OIDC) authentication. Registering the application in Azure sets up a secure trust relationship between your app (e.g., Cube Cloud, Superset, or ArgoCD) and Azure AD. This registration provides essential values like the Client ID, Client Secret, and OIDC endpoints, which are used to authenticate users, enforce access control, and enable secure single sign-on (SSO).

  1. Go to the Microsoft Azure Portal.

  2. Search for the App Registrations service. This is under Identity.

  3. Click New registration.

  4. Provide a name for the new application.

  5. For Supported account types, keep the current selection.

  6. Under Redirect URI > Select a platform, choose Web.

  7. Click Register.

  8. In the side bar, go to Manage > Certificates & secrets.

  9. Click New client secret.

  10. Add a name for the new client secret.

  11. Click Add.

  12. Copy the Client Secret Value and the Client Secret ID. Save the details.

Configuring API Permissions for the Azure AD Collector​

To enable the Azure AD Collector to retrieve directory data, specific Microsoft Graph API permissions must be granted to the registered application. Follow the steps below to assign the necessary permissions and ensure the collector functions as intended.

  1. Select your registered application from the list.

  2. In the left sidebar under Manage, click API permissions.

  3. Click Add Permissions.

  4. Select Microsoft Graph, then Application permissions.

  5. Under Select permissions, type Directory into the search box.

  6. In the search results, expand the Directory section and check Directory.Read.All.

  7. Click Add permissions to confirm.

  8. Ask the administrator to grant the admin consent for the registered application.

Configuring Keycloak for OIDC Authentication​

In this section, you’ll configure Keycloak as an OIDC broker for the application. This includes setting up a new realm, registering an OIDC client, and connecting Keycloak to Microsoft Entra ID as an external identity provider. You’ll also define administrative users to manage authentication and access within the realm. These steps prepare Keycloak to act as a central broker between users and the application, enabling secure and flexible login flows.

  1. Go to the Keycloak Admin URL and log in with your administrator credentials.

  2. In the sidebar, click Manage Realms, then select Create Realm.

  3. Provide a name for the realm and click Create.

  4. In the left sidebar under Manage, select Clients, then click Create Client.

    • Under General Settings, configure the following:
      • Leave Client Type as OpenID Connect.
      • Provide a Client ID.
      • Enter a unique name for the client.
      • (Optional) Add a description.
      • Click Next.
    • Under Capability Configuration:
      • Enable Client Authentication.
      • Check Service Accounts Roles under Authentication Flow.
      • Click Next.
    • Under Login Settings:
      • Set Root URL to your application’s domain.
      • Set Home URL to the same domain.
      • Add the following to Valid Redirect URIs:
        • <your-domain>/authentication/oauth2/generic/authorization-code-callback
        • <your-domain>/superset/oauth-authorized/SSO
      • Click Save.

Updating Realm Settings​

  1. In the sidebar, click Manage Realms, then select the created realm.

  2. In the left sidebar, under Configure, select Realm settings.

  3. Go to the Keys tab, then click Add Providers.

  4. Select rsa-enc-generated, disable Enabled and Active, then click Save.

  5. Go to the Sessions tab and set the SSO Session Idle value to 2 hours.

  6. Click the Save button at the bottom of the page.

  7. Go to the Tokens tab. Under Access tokens, set the value of Access Token Lifespan to 2 hours.

  8. Click the Save button at the bottom of the page.

Creating Admin Users​

  1. In the sidebar under Manage, click Users, then click Add User.

  2. Fill out the required user details (username, email, etc.).

  3. Click Create.

  4. Note the email addresses of the admin users — they must be included in the OPENIT_ADMINISTRATORS environment variable, which will be set later in the Setting up Secret Keys section.

Configuring the Identity Provider​

  1. In the sidebar under Configure, click Identity Providers, then Microsoft.

  2. Provide the required details:

    • Alias - a name to identify the provider in Keycloak.
    • Client ID - from the customer’s app registration.
    • Client Secret - from the customer’s app registration.
    • Tenant ID - from the customer's Microsoft Entra ID (Azure AD).
    • Click Add.

    note

    After adding the identity provider, Keycloak will generate a Redirect URI. This URI must be provided in the customer’s Azure App Registration as a valid redirect URL.

Deploying Cube Cloud​

This section describes how Cube Cloud is deployed as a semantic layer that connects to AWS Athena and exposes fast, secure data APIs. Configuration is managed through a GitLab repository, enabling version control and automated deployment.

  1. Go to https://openit.cubecloud.dev/.

  2. Log in with your account.

  3. In the upper-right corner of the page, click Create Deployment.

  4. Under Create Deployment:

    • Name your deployment - provide a unique name for your deployment
    • Select a cloud platform - choose Amazon Web Services
    • Select a region - select the closest region to the customer
    • Click Next.

  5. Under Set Up Cube Project:

    • Choose Import GIT repository via SSH / HTTP.

    • Click Generate SSH Key.

      • SSH Key - copy the generated SSH Key and save it. It will be used later for the Gitlab repository.

        • Adding SSH Key to GitLab

        a. Go to https://gitlab.com/.
        b. Log in using your credentials.
        c. Click the User icon > Preferences.
        d. In the side bar, click SSH Keys.
        e. Click Add new key.
        f. Paste the generated SSH Key from Cube Cloud.
        g. Click Add key.

      • GIT Repo URL - use git@gitlab.com:openitdotcom/semantic-layer/cube.git. This repository contains the Cube.js data schema and logic for usage data modeling specifically to Open iT's lab environment.
      • Default branch - use master

    • Click Connect.

  6. Under Set Up a Database Connection, choose AWS Athena.

    • AWS Access Key ID - A unique identifier for your IAM user or role.
    • AWS Secret Access Key - The private key paired with your Access Key ID — like a password for programmatic access.
    • AWS Region - The specific AWS geographic area where your Athena resources are located (e.g., us-east-1, ap-southeast-1).
    • AWS Athena Workgroup - A named configuration group in Athena that defines query settings (e.g., primary (default), cube-workgroup (custom))
    • Click Apply.
    • Click Connect.

Adding Cube Cloud Environment Variables​

The Cube Cloud environment variables are used to configure connections, authentication, data sources, and feature behavior within your deployment. This section guides you through adding the necessary variables to ensure that Cube Cloud can connect to services like AWS Athena and operate as expected in your environment.

  1. Click the name of your Cube Cloud deployment.

  2. In the sidebar, select Settings.

  3. Select Environment Variables.

  4. Click Show All Variables. To view the current values of the predefined environment variables, you can also click Reveal All Values.

  5. Add the required variable(s):

    Environment VariablesDescription
    OPENIT_TENANT_IDSpecifies the specific tenant (organization/account) for the current Cube deployment. This is the s3_glue_tenant_id from the Terraform output.
    OPENIT_APPLY_AUTHORIZATIONSpecifies flag to enable or disable authorization enforcement for Cube's internal logic. The value should be false.
    OPENIT_AUTHORIZATION_URLSpecifies the URL of the authorization service or endpoint Cube uses to validate incoming tokens or check user access. The value should be https://<domain_name>authorization, where <domain_name> is the domain_name from the Terraform output.
    CUBEJS_SCHEDULED_REFRESH_TIMEZONESSpecifies the timezone(s) used for scheduled pre-aggregations and refresh tasks. The value should depend on the timezones of the users. For example, UTC,Asia/Manila,Europe/Oslo,Asia/Shanghai,Asia/Singapore.
    CUBEJS_DEFAULT_API_SCOPESSpecifies the default scope or permission level assigned to API tokens when no specific scopes are explicitly provided. The value should be meta,data,graphql,jobs.
    CUBEJS_AWS_S3_OUTPUT_LOCATIONSpecifies the Amazon S3 path where Cube.js should store query results, particularly when using AWS Athena as a data source. The value should be s3://<staging-openit-s3>/athena_result/.
    CUBEJS_JWK_URLSpecifies the URL to a JSON Web Key Set (JWKS) endpoint used to verify JWT tokens. The value should be https://login.microsoftonline.com/<tenant_id>/discovery/v2.0/keys, where <tenant_id> is the Directory (tenant) ID from the Azure Portal (Home > App Registrations > Overview).
    Cube Cloud Environment Variables

    For each variable name and value pair, click the inline plus button to add it to the list.

    warning

    Verify and validate all environment variable values before proceeding to avoid issues during deployment.

Updating Cube Cloud Repository​

  1. Click the name of your Cube Cloud deployment.

  2. In the sidebar, select Settings.

  3. Select Build & Deploy.

  4. Click Change Repository, then Disconnect this Repository.

  5. Connect to a new repository again. Provide a new repository URL and set up authentication.

Setting up Secret Keys​

Here’s a list of secret keys that must be correctly set for the services to function properly. Some of these values are automatically provisioned by Terraform during the setup process.

Secret KeysDescription
AWS_ACCESS_KEY_IDSpecifies the identifier for your AWS IAM user or role. It tells AWS who you are when making programmatic requests. This is used together with the AWS_SECRET_ACCESS_KEY to authenticate with AWS services.

This is the temporary AWS credentials generated by assuming the admin role.
AWS_DEFAULT_REGIONSpecifies the default AWS region your CLI commands will target if no region is explicitly defined.
AWS_DEPLOYMENTSpecifies a flag or tag indicating the deployment target or environment type.
AWS_SECRET_ACCESS_KEYSpecifies the secret credential used to securely sign your requests to AWS.

This is the temporary AWS credentials generated by assuming the admin role.
DATABASE_DBSpecifies the name of the primary application database that contains data to be visualized and queried.
DATABASE_DIALECTSpecifies the type of database being used (e.g., postgresql, mysql, etc.).
DATABASE_HOSTSpecifies the hostname or IP address of the database server.
DATABASE_PORTSpecifies the port number on which the database is listening.

The default for PostgreSQL is 5432.
DATABASE_SUPERSET_DBSpecifies the name of the database that the application should connect to.

The value should be superset.
DATABASE_USERSpecifies the username used to connect to the database.
OPENIT_ADMINISTRATORSSpecifies the comma-separated list of administrator email addresses. These users are given elevated access or permissions in the system. These are the email addresses of the users with administrator access. Users who are not administrators will automatically be assigned the Gamma role in Superset by default.
OPENIT_AUTHENTICATION_OIDC_BASE_URLSpecifies the base URL of the OIDC identity provider.

The value should be https://login.microsoftonline.com.
OPENIT_AUTHENTICATION_OIDC_CLIENT_IDSpecifies the client ID of your registered application in Azure AD.

This is the Application (client) ID from Azure Portal (Home > App Registrations > Overview).
OPENIT_AUTHENTICATION_OIDC_CLIENT_SCOPESSpecifies the level of access and types of information the application wants to retrieve from the OIDC provider (e.g., user identity details, email, profile info, or access to APIs).

This accepts a space-separated list of OIDC scopes.
OPENIT_AUTHENTICATION_OIDC_CLIENT_SECRETSpecifies the client secret generated in Azure AD when registering the application.

This is the value from Azure Portal (Home > App Registrations > Certificates & secrets > New client secret).
OPENIT_AUTHENTICATION_OIDC_CLIENT_TYPESpecifies the type of client authentication method for the configured OIDC (OpenID Connect) provider. When a secret is provisioned, the default value is basic.

The value of the secret should be adjusted based on OIDC implementation used:
  • Azure AD - form
  • Zitadel - basic
  • Keycloak - basic
OPENIT_AUTHENTICATION_OIDC_METADATA_URLSpecifies the full URL to the OIDC discovery document (metadata endpoint).

This is the OpenID Connect metadata document from Azure Portal (Home > App Registrations > Overview > Endpoints).
OPENIT_AUTHENTICATION_OIDC_TOKEN_URLSpecifies the OIDC endpoint used to exchange authorization codes for tokens.

This is the OAuth 2.0 token endpoint (v2) from Azure Portal (Home > App Registrations > Overview > Endpoints).
OPENIT_AUTHENTICATION_OIDC_WEB_CLIENT_IDSpecifies the Client ID assigned to the web-based frontend application during its registration with the OpenID Connect (OIDC) provider (e.g., Keycloak or Azure AD).
OPENIT_AUTHENTICATION_OIDC_WEB_CLIENT_SECRETSpecifies the Client Secret associated with the web application’s OIDC client registration. It acts like a password shared between the application and the OIDC provider.
OPENIT_AUTHENTICATION_OIDC_WEB_SCOPESSpecifies a space-separated list of OIDC scopes that the application requests from the identity provider during user authentication.
OPENIT_CUBEJS_POSTGRE_DBThe name of the PostgreSQL database that Cube.js will connect to.

This is the Database from Cube Cloud (Your _Deployment > Integration > API Credentials > SQL API).
OPENIT_CUBEJS_POSTGRE_HOSTThe hostname or address of the PostgreSQL server instance.

This is the Host form Cube Cloud (Your _Deployment > Integration > API Credentials > SQL API).
OPENIT_CUBEJS_POSTGRE_PASSWORDThe password used to authenticate the PostgreSQL user defined in OPENIT_CUBEJS_POSTGRE_USERNAME.

This is the Password form Cube Cloud (Your _Deployment > Integration > API Credentials > SQL API)
OPENIT_CUBEJS_POSTGRE_PORTThe port number used to connect to the PostgreSQL database that supports Cube.js.
OPENIT_CUBEJS_POSTGRE_USERNAMEThe username used by Cube.js to authenticate with the PostgreSQL database.
OPENIT_CUBEJS_TIMEZONESSpecifies which time zones the Cube Cloud instance should recognize and handle correctly when processing queries, dashboards, and data refreshes. This accepts a comma-separated list of time zones.
OPENIT_CUBEJS_URISpecifies the URL of the Cube.js API endpoint that external applications or services should communicate with.

This is the URI from Cube Cloud (Your _Deployment > Integration > REST API > Endpoint, until “.dev” only)
OPENIT_JWT_AUTHORITYSpecifies the authorization server URL (issuer) responsible for issuing and validating JWTs (JSON Web Tokens) for Open iT services.
OPENIT_JWT_CLIENTIDSpecifies the client identifier generated after registering a JWT client in the Open iT Customer Portal.

Recommended reading: Generating the Client ID and Secret in the Customer Portal
OPENIT_JWT_CLIENTSECRETSpecifies the client secret associated with the JWT client ID, also obtained from the Open iT Customer Portal.

Recommended reading: Generating the Client ID and Secret in the Customer Portal
OPENIT_SiteBindings__0__HostSpecifies the host binding for the first site configuration in the Open iT application for routing or service discovery.
OPENIT_TENANT_IDSpecifies a unique identifier for the tenant (organization, customer, or environment) associated with this deployment.
SUPERSET_SECRET_KEYSpecifies a secret string used by Apache Superset for cryptographic operations.
Secret Keys