Skip to content

Feat: Kusion Server apply can use KubeConfig from a secret provider #1409

@ffforest

Description

@ffforest

What would you like to be added?

Kusion Server should be able to add KubeConfig needed for preview, apply and destroy.
Suggestion is to:

    1. add the ability (API and GUI) to upload a kubeconfig, store the kubeconfig in a specified secret provider (supporting aws, azure, gcp, alicloud and viettel cloud currently), return a secret reference (ref://xxx/xxx/xxx), and later reference the kubeconfig in the workspace config (this is already supported)
      and/or
    1. support directly retrieving a pre-existing kubeconfig from a supported secret provider.

The difference between the two is the first one doesn't require the user to be familiar with the specific secret provider per se because the secret lifecycle is entirely contained within Kusion. The second one require a step to upload the kubeconfig by the user, which is more complex but provides more flexibility. We can support both too.

Why is this needed?

Kusion determines the KubeConfig used by a preview, apply and destroy operation by reading the KUBECONFIG_PATH or KUBECONFIG_CONTENT. See here for details.
However this requires either the kubeconfig to be stored on the server (when using KUBECONFIG_PATH, or the kubeconfig content to be exposed in the Spec, which is unsafe).
The proper place to store sensitive info like a kubeconfig is the secret provider, which kusion already supports. So adding the ability to process KubeConfigs there is reasonable.

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/featureCategorizes issue or PR as related to a new featurepriority/important-longtermP2, may not be staffed and/or may need multiple releases to complete

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions