[proposal]: Align config and profiles with kubeconfig semantics

[tnthornton]

What problem are you facing?

As usage has grown for up, we've gone through a few different phases of attempts to manage authentication/contexts with different systems:

• different environments (dev, staging, prod)
• wholly different API surfaces areas (cloud vs spaces)
• even in some cases attempting to model kube contexts on top of the pre-existing system.

This has left us in a state where:

• The up config and profile system is hard to work with.
• Not intuitive.
• Brittle.
• Continues to be more and more complex as new use cases are introduced.

How could Upbound help solve your problem?

This issue proposes that we replace the config and profile constructs with kubeconfig semantics:

• Remove the usage of ~/.up/config
• Move to strictly using the Kubeconfig API schema.
• Move current commands for up config and profile to working against the new config - most likely we can just mimic the same commands that kubectl currently offers.

Within the kubeconfig, we could:

• set contexts for cloud versus a space.
• set contexts for the different environments.
• use the auth block for authenticating with the target.

In general this will benefit current consumers and future consumers:

1. For those familiar with kubectl, they get a familiar API to work against.
2. If you're working with a control plane or a space, bouncing between up and kubectl becomes less of a mental switch.

[AlainRoy]

I love the idea that you're thinking this through!!! ❤️ I agree that this is one of the more confusing bits of the up CLI.

I'm not an expert with the Kubeconfig schema, so a couple of questions that may be stupid:

• Would we use the same kubeconfig that kubectl uses? Would it cause confusion for the Upbound SaaS to be listed there? It's not something that kubectl could use as normal.
• Today, up login stores the session ID in the configuration file. Is there a place for that in the kubeconfig? Would it a token in the AuthInfo? (I'm not really pushing for a technical decision, just making sure it's feasible.)
  • Same question for the account/org.
• One question I often have is "what is my config pointing at? Is it Upbound SaaS, a Space, or a control plane?" Would we have a way to annotate that in the config, so we could help customers know? Or would they just use the name of the Kubernetes cluster and figure it out from there?

[tnthornton]

@AlainRoy all good questions. I think we have a number of options with how we could address those concerns/questions. If we get buy in that this is reasonable enough to move to do a one pager/POC, we can explore possible answers to each of those.