Add support for managing Kyma environments on SAP BTP in Kyma CLI

[kwiatekus]

Description:

Introduce a new set of capabilities in the Kyma CLI to allow users to manage Kyma environments on SAP BTP using the SAP BTP Terraform provider and the official Kyma Terraform module

Terraform integration

Kyma CLI would delegate provisioning to terraform (based on known main.tf file, see examples) and store terraform state and metadata in:

~/.kyma/instances/{instance-name}/

Includes:

• Terraform state
• Module/provider cache
• kubeconfig file

New capabilities of CLI

New kyma instance subcommands:

• kyma instance list
  Lists all Kyma environments from local state.

• kyma instance create {name}
  Provisions a new Kyma environment on SAP BTP with the given name and stores the state in the local store.
  Support for --dry-run --output-dir that would only output terraform configuration into the target dir. User can procede with terraform CLI in such case

• kyma instance delete {name}
  Deletes the Kyma environment with the specified name and cleans up local store.

• kyma instance get {name}
  Reads the Kyma environment metadata from local store and via terraform output command, including cluster domain, service instance id, btp subaccount id

• kyma instance kubeconfig get {name}
  Reads the kubeconfig for a Kyma environment from a local store
  Support --use flag in instance kubeconfig to immediately activate the fetched kubeconfig.

• kyma instance kubeconfig rotate {name}
  Rotate access on BTP, stores in local store and outputs the credentials.
  Support --use flag in instance kubeconfig to immediately activate the fetched kubeconfig.

Configuration Options

Kyma CLI supports flexible configuration through:

1. Command-line flags (highest priority)

kyma instance create my-instance \
  --btp-new-subaccount-name "demo-subaccount" \
  --btp-kyma-region "europe" \
  --env-path ./btp-env.env

2. .env file (via --env-path)

--env-path ./btp-env.env

Configuration Precedence

1. Command-line flags
2. .env file from --env-path
3. Default: ~/.kyma/btp.env

Example .env File

BTP_NEW_SUBACCOUNT_NAME=""
BTP_NEW_SUBACCOUNT_REGION=""
BTP_GLOBAL_ACCOUNT=""
BTP_USERNAME=""
BTP_PASSWORD=""
BTP_BACKEND_URL=""
BTP_CUSTOM_IAS_TENANT=""
BTP_KYMA_PLAN=""
BTP_KYMA_REGION=""
BTP_KYMA_CUSTOM_ADMINISTRATORS=["",""]

Future Ideas

Instance switching and context awareness:

• kyma instance use {name}
  Sets the specified instance as the current CLI context. Stores context info in ~/.kyma/current.

• kyma instance current
  Displays which Kyma instance is currently active (based on kubeconfig context or local CLI context).

Technical considerations

• CLI will use the Terraform underneath:

  • from a host machine ? (good opportunity to start a dev-toolbox)
  • via go client ? (like we use pack already)

• Underlying providers:

  • SAP BTP Terraform provider
  • Kyma Terraform module

[kwiatekus]

As a first step we should start with this feature
#2474

In the end it might be sufficient to make it easier to close the gap in the automation path between terraform and SAP BTP terraform provider