You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Kusion Server should be able to add KubeConfig needed for preview, apply and destroy.
Suggestion is to:
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
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.
The text was updated successfully, but these errors were encountered:
What would you like to be added?
Kusion Server should be able to add KubeConfig needed for
preview
,apply
anddestroy
.Suggestion is to:
ref://xxx/xxx/xxx
), and later reference the kubeconfig in the workspace config (this is already supported)and/or
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
anddestroy
operation by reading theKUBECONFIG_PATH
orKUBECONFIG_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.
The text was updated successfully, but these errors were encountered: