Config Contexts using Custom Input

Overview

This feature enables a single, reusable environment template to provision Amazon EKS clusters across multiple AWS accounts while maintaining project-level isolation.

Environment templates support dynamic config context naming and project-scoped configuration values, allowing templates to reference pre-associated and validated infrastructure details without requiring users to provide low-level identifiers such as VPC IDs, subnet IDs, KMS keys, or IAM role ARNs.

Each project can expose only its permitted accounts and configuration values, ensuring controlled visibility while using the same shared templates. This allows platform administrators to centrally manage and share environment templates without duplicating them for each project, supporting scalable, multi-project, multi-account deployments.

---

Step 1: Select Config Context Using Custom Input

While creating or editing a resource template, navigate to the Config Contexts section.

By default, config contexts can be selected using Select from list, where an existing config context is chosen from a dropdown.

Select Custom input to enter a config context name directly instead of choosing it from the list. This option allows specifying the config context name using static text, expressions, or a combination of both.

Example

app-#{project.name}#-cc

Supported Expressions

Scope	Expression
Project	project.name
Project	project.id
Project	project.tags.<key>
Organization	organization.name
Organization	organization.id
Partner	partner.name
Partner	partner.id

These expressions can be combined with static text to construct dynamic config context names.

At this stage, the referenced config context may not exist in the project. This is expected behavior, as the expression is evaluated later during environment deployment. The resource template can be saved as a draft even if the referenced config context is not currently present.

Once the resource template version is saved, the configured Custom input value appears in the Contexts section of the version details. The config context is displayed exactly as entered, including any expressions, confirming that the template is configured to resolve the config context name dynamically at deployment time.

To use the resource template, a config context must be created in the project using the same naming pattern defined in the Custom input.

When the template is applied, the platform looks for a config context whose name matches the evaluated pattern for the project. That config context is then associated with the deployment.

Step 2: Create an Environment Template Using the Resource Template

Create an environment template using the resource template configured with the Custom input for config context selection and Save as an Active Version

The environment template inherits the config context configuration defined in the resource template. Once created, the environment template can be shared across multiple projects.

This allows the same environment template to be reused while resolving project-specific config contexts dynamically during deployment.

Step 3: Share the Environment Template Across Projects

After creating the environment template using the resource template, share the environment template with other projects.

Sharing the environment template makes it available for use across multiple projects while keeping the config context name defined using Custom input.

Once the environment template is shared, each project that uses it must create a config context that follows the same naming pattern defined in the Custom input, including the project name.

The environment template can be shared with all projects, while each project maintains its own config context using the same naming convention.

After the environment template is shared, switch to another project where the template is available.

When attempting to use the shared environment template in the project, the required config context must already exist in that project. If the config context following the defined naming pattern is not present, the environment template cannot be used.

Create the config context in the project using the same naming pattern defined in the Custom input. This config context is then used to associate project-specific configuration values with the shared environment template.

Step 4: Create a Project-Specific Config Context and Add Restricted Key Values

In each project that uses the shared environment template, create a config context whose name follows the naming pattern defined in the Custom input.

For example, using the configured pattern:

app-#{project.name}-cc

If the project name is kpdproject, the config context created in that project must be named:

app-kpdproject-cc

This config context is created at the project level and is used to store configuration values specific to that project.

• Within the config context, add input variables that represent project-scoped values, such as cloud accounts.

• When creating an input variable:

  • Set Override to Restricted Key Values

  • Use Add Restricted Key Values to define the allowed options for the project

    Example:

    • Key: accounta
    • Value: detailsa

  • Add additional entries for the same variable as needed.

    Example:

    • Key: accountb
    • Value: detailsb

• Each key appears as a selectable option when launching the environment, while the corresponding value is passed to the deployment workflow.

• Before saving the variable, select a Value Type, which is mandatory. Supported value types include Text, JSON, and Expression.
• If JSON is selected, use the Validate JSON option to verify that the JSON content is valid before saving.

• The Default Value must be set to one of the keys defined under Restricted Key Values. This determines which key is selected by default when the environment is launched.

For example, if accounta and accountb are defined as restricted keys, the default value can be set to accounta or accountb.

• Click Save

Each project creates and manages its own config context and restricted key values using the same naming pattern, while continuing to use the shared environment template.

Step 5: Launch the Environment and Select Project-Specific Values

When launching an environment using the shared environment template, variables configured with Restricted Key Values appear in the Parameters section.

Only the keys defined in the project’s config context are displayed in the dropdown.

For example, if the project’s config context contains the keys accounta and accountb, only those options appear for the accounts parameter.

Select the required key and proceed with Save & Deploy. The value associated with the selected key is passed to the deployment workflow and used during provisioning.

This ensures that each project can select only its own permitted configuration values while using the same shared environment template.

This workflow enables shared environment templates to be used across multiple projects while keeping configuration values isolated at the project level.

By combining Custom input for config context naming with Restricted Key Values inside project-specific config contexts, each project can expose only its permitted configuration options, such as cloud accounts. During environment launch, users select from a controlled set of values, and the selected value is applied to the deployment.

This approach allows centralized template management with consistent naming while ensuring project-specific configuration control and safe reuse across multiple projects.

---