What problem are you facing?

There is only main builds of UXP.

How could Universal Crossplane help solve your problem?

We need to release the first version of UXP images and Helm charts and make sure it works before GA.

What happened?

Tag we have in master right now is v1.3.0-up.1-rc.0. Below you can see some of the versions we've generated from master with this version:

1.3.0-up.1.rc.0.2-ge7c4d09
1.3.0-up.1.rc.0.9-g86eba06
1.3.0-up.1.rc.0.11-ga5ee7ca
1.3.0-up.1.rc.0.22-g669eead

The problem with these versions is, they cannot be sorted properly as semantic versions. Semver libraries splits pre-release part (e.g. up.1.rc.0.2-ge7c4d09) with . and compare each piece from left to right. In this comparison, 9-g86eba06 calculated as greater than 11-ga5ee7ca which is not correct.

This prevents finding the latest available version using standard semver libraries.

We also saw the same problem in the output of helm search repo which sorts versions and the one on top expected to be the latest:

$ helm search repo -l upbound-main/universal-crossplane --devel

NAME                             	CHART VERSION              	APP VERSION                	DESCRIPTION
upbound-main/universal-crossplane	1.3.0-up.1.rc.0.9-g86eba06 	1.3.0-up.1.rc.0.9-g86eba06 	Upbound Universal Crossplane (UXP) is Upbound's...
upbound-main/universal-crossplane	1.3.0-up.1.rc.0.22-g669eead	1.3.0-up.1.rc.0.22-g669eead	Upbound Universal Crossplane (UXP) is Upbound's...
upbound-main/universal-crossplane	1.3.0-up.1.rc.0.20-g23d464e	1.3.0-up.1.rc.0.20-g23d464e	Upbound Universal Crossplane (UXP) is Upbound's...
upbound-main/universal-crossplane	1.3.0-up.1.rc.0.2-ge7c4d09 	1.3.0-up.1.rc.0.2-ge7c4d09 	Upbound Universal Crossplane allows you to conn...
upbound-main/universal-crossplane	1.3.0-up.1.rc.0.17-g076d121	1.3.0-up.1.rc.0.17-g076d121	Upbound Universal Crossplane (UXP) is Upbound's...

We should either adapt the tag we are using on master (which should contain only one hyphen, e.g. just v1.3.0-rc.0) or update build submodule such that it is generating valid versions with this tag as well.

How can we reproduce it?

https://play.golang.org/p/ZlzB7izzGdJ

What environment did it happen in?

Universal Crossplane version: versions from master
Kubernetes version (kubectl version): NA

It deletes my kind cluster but the control plane is left there and when you try to connect to it with a new kind cluster it says:

upbound-agent: error: failed to create new agent proxy: failed to connect NATS: new token request failed with 400 Bad Request - {
                        "message": "this control plane is registered for another kubernetes cluster"
                      }

make local.down should delete the control plane it created so that experience is smoother.

Here is the format, we want to use the latest bundle: https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/building-your-csv.md

That's a script @kasey wrote a while ago but needs to be updated or rewritten: https://github.com/kasey/operator-hub-update-4-crossplane

Here is the list of published Crossplane entries:

• Upstream Operators https://github.com/operator-framework/community-operators/tree/master/upstream-community-operators/crossplane
• Openshift https://github.com/operator-framework/community-operators/tree/master/community-operators/crossplane

Here is a doc explaining to where the operator should go, in our case we should add it to both.

We want to limit the Secret access of the distro to certain namespaces. crossplane-edit has access to all Secrets in all namespaces. If add a condition in that YAML, we can control whether that permission is included in UXP installation.

What we want to do is likely to have access to Secrets in the namespace UXP is deployed so that it's easier for users to create credentials secret. However, if they want to use other namespaces to store Secrets, they will have to create a Role that grants access to that Secret and bind it to ServiceAccount of UXP using RoleBinding.

Problem: We need to name this package for the Upbound distribution. This package includes the agent or other components.

https://github.com/upbound/crossplane-distro/blob/1e683c501166e9b703f8ab60d493dd9f54395d50/charts/project-uruk-hai/Chart.yaml#L4

Decision:
helm install upbound-universal-crossplane

AWS folks suggested to look at Akka Cloud entry as an example of Helm chart in AWS Marketplace.

What problem are you facing?

We need to submit the AWS Marketplace product listing before this repo is public, hence it cannot access the logo file. I created an S3 bucket in marketplace account with marketplace-media and put the logo there, publicly accessible. But that's an obscure bucket in an account not many of us have or need access.

How could Universal Crossplane help solve your problem?

We can use public URL of the logo in this repo once it's opened up.

We need a configmap that contains component versions as discussed this ticket.

/cc @thephred

What problem are you facing?

Contributors can see how OLM bundle is made and how to validate it here. AWS Marketplace is mostly UI clickops. But we just don't cover that information anywhere and I feel like it can be easily forgotten during the releases because they both involve manual steps.

How could Universal Crossplane help solve your problem?

We should have a doc explaining how to release UXP, what to do at what step and include all distributions and their details.

What problem are you facing?

When you deploy Universal Crossplane, bootstrapper fetches the UbC TLS public key JWT public key from Upbound (requires authorization) and then populates the Secret that both upbound-agent and crossplane-graphql mounts so that they can start. However, this causes for those Pods to be in CreateConfigError for a while. It's not a blocker for anything but it's not a good UX either.

How could Universal Crossplane help solve your problem?

Each server that required UbC TLS JWT public key can fetch it from UbC on its own when it starts. One caveat there is that the endpoint requires login but that's not really necessary because public key of UbC is not confidential.

What problem are you facing?

Enterprises use tools like Rancher Catalog to centralize management of packages installed into Kubernetes clusters, and avoid sprawl and misconfiguration at scale. By being in the Rancher Catalog, Rancher customers have a frictionless way of installing UXP to their application clusters so developers can self-service infrastructure.

This is a shorter name and likely what will stick in the community. I don't believe this needs to be done for first release, just tracking here.

We need a couple of (mostly one-time) operations during installation UXP (a.k.a crossplane-distro):

• SSL certificate creation (for gateway, graphql and crossplane webhooks)
• Fetching NATS CA and JWT public key for token verification
• Creation of UbC control planes (if we want auto-connect)
• Coordinating licensing with AWS

and we expect more to be added to this list as our product grows and more integrations added.

Since we were looking for a simple solution as a first step, we were planning to implement these with the mechanisms provided by Helm, e.g. crypto template functions and installation hooks.

However, this would not work with OLM as it does not support any helm mechanism or any templating at installation time. So we need an alternative solution here.

We discussed, with @muvaf, the following options as a solution:

a. Decentralize this by distributing the work to the most relevant components, for example:
Crossplane, as the only component which is always being deployed, could generate certificates for the gateway, graphql, and webhooks.
Gateway, could create UBC control planes if not created if we want auto-connect.
However, this does not sound like a good idea as it is hard to find a relevant component for this sort of operations (e.g. AWS licensing) and causing dependencies (gateway/graphql needs crossplane for certs) that is hard to justify.

b. Build a full-fledged operator which coordinates installation including this sort of operations.
This seems to be the most appropriate solution in the long term and the best fit for the OLM deployment model (as it expects an operator). However, this has some caveats around RBAC and requires some work.

c. Introduce a new component responsible for this sort of installation or bootstrapping operations.
We could introduce a new component responsible for bootstrapping UXP. We still deploy our components with helm (or in the case of OLM, include manifests in the package) but handle other installation operations with this component. This approach seems to be most straightforward at this point, however, this is still limited since this bootstrapper has no control over the deployment configuration of other components. This component could evolve to an operator once/if we blocked by this limitation.

Option a. feels hacky and will not scale. The cleanest solution (esp. for OLM) seems to be building an operator coordinating the installation (option b.). However, to move fast, we want to go with option c as an interim solution which could also evolve to option b if needed.

We implemented the olm-bundle tool to generate OLM bundles. Now that all expected big package changes landed, we'd like to use it and add OLM bundle in cluster/olm.

We want to publish in GitLab ADO but it seems we will probably work with a vendor to do this.

AC

• Understand whether or not we can simply update the ADO integration to point to a new helm chart (the to be released Upbound one) or if we have to do deeper integration work
• Estimate of any deeper integration work required
• Make a recommendation about whether or not we should pay Infracloud to update the listing or if we should do this ourselves

RedHat recommends use of Universal Base Image as the base image of OperatorHub projects.

We can switch to that for images we're using in OperatorHub. Though it's worth noting this will only capture images of UXP, not images of providers.

What happened?

We are versioning our stable artifacts in the following format: x.y.z-up.n. However, as per semver specification, these versions considered to be pre-release.

This is fine as long as we consume uxp packages via up cli, however, causing problems when they need to be consumed by external tooling.

We've been observing this problem with helm cli, however, up cli being our primary installation method and helm having --devel option as a workaround, this considered as a low priority issue so far.

Now, I am having a similar problem while working on publishing UXP to Rancher catalog. UXP charts with the current version format not visible in the UI unless the user intentionally enables "Include Prerelease Versions" option under preferences.

How can we reproduce it?

$ helm repo add upbound-stable https://charts.upbound.io/stable && helm repo update

$ helm search repo -l upbound-stable/universal-crossplane
No results found

$ helm search repo -l upbound-stable/universal-crossplane --devel
NAME                               	CHART VERSION	APP VERSION	DESCRIPTION
upbound-stable/universal-crossplane	1.2.1-up.3   	1.2.1-up.3 	Upbound Universal Crossplane allows you to conn...
upbound-stable/universal-crossplane	1.2.1-up.2   	1.2.1-up.2 	Upbound Universal Crossplane allows you to conn...
upbound-stable/universal-crossplane	1.2.1-up.1   	1.2.1-up.1 	Upbound Universal Crossplane allows you to conn...

What environment did it happen in?

Universal Crossplane version: 1.2.1-up.3
Kubernetes version (kubectl version): N/A

Now that xgql is written in Go and agent was already in Go, all parts of Universal Crossplane are written in Go. As mentioned in design doc, I think it makes sense for us to move both xgql and agent to this repo and produce their images from here.

For versioning, @turkenh suggested using v1.2.0-up.1 where v1.2.0 is Crossplane version and up.1 is distro version, similar to GKE using 1.18-gke.156. All images (bootstrapper, agent and xgql) would use the same version tag.

AWS Marketplace requires all container images to be pushed to an ECR repositories that we register in Marketplace so that they can scan for security vulnerabilities and that includes open source images as well, i.e. we'll need to push crossplane/crossplane image, too.

In order to do that, we need to have a variant in the build & push pipeline to push to that registry. The tricky part is about how we can use those images in the Helm chart. In #22 , I added a %%IMAGE_REGISTRY%% variable. We can use that to build an alternative Helm chart with ECR registry and push that to ECR Helm repo and use it in AWS Marketplace installation instructions.

Per https://github.com/upbound/wesaas/issues/795 and https://github.com/upbound/features/issues/369 we'd like to simplify the UXP security model such that the Upbound Agent can only impersonate a fixed set of groups. These groups would correspond to (and thus should be bound to) the crossplane-admin, crossplane-edit, and crossplane-view RBAC ClusterRoles that are created by the Crossplane Helm chart.

Previously crossplane-graphql was responsible for managing bindings from team-scoped groups to these RBAC roles. With the simpler groups it should be possible for the UXP Helm chart to create bindings from these groups to their equivalent ClusterRoles at install time.

What problem are you facing?

I'm about to merge #80, which removes the local dev instructions from the README. This could make it tough for folks to figure out how to develop UXP.

How could Universal Crossplane help solve your problem?

We should add a CONTRIBUTING.md file and link it from README.md. The docs should keep in mind that many contributors won't be Upbound employees.

What problem are you facing?

Upbound Cloud currently shows folks the "Crossplane Version" they're running for a particular control plane. In practice we run UXP and would like to more specifically show folks the "UXP Version" they're running.

How could Upbound help solve your problem?

We could add a uxpVersion key with the running UXP version (e.g. 1.2.1-up.3) to the config map.

What happened?

Browsed the Registry, selected Configurations.
Saw that "getting-started" lacks a logo

How can we reproduce it?

visit https://cloud.upbound.io/browse
Select "Configurations" from Filter By / Type
Note the appearance of the "getting-started" configuration

What environment did it happen in?

Production

Universal Crossplane version: v1.2.1-up.3
Kubernetes version (kubectl version):
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.7", GitCommit:"1dd5338295409edcfff11505e7bb246f0d325d15", GitTreeState:"clean", BuildDate:"2021-01-13T13:23:52Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.17", GitCommit:"f3abc15296f3a3f54e4ee42e830c61047b13895f", GitTreeState:"clean", BuildDate:"2021-01-13T13:13:00Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/arm64"}

What happened?

The default values.yaml in the UXP helm chart is stale with respect to Crossplane. For instance, the securityContext fields on release-1.2 do not match those for v1.2.1 in Crossplane.

How can we reproduce it?

Deploy UXP and check the runAsUser / runAsGroup fields.

What environment did it happen in?

Universal Crossplane version: v1.2.1-up.3
Kubernetes version (kubectl version): v1.21.0 (v1.21.0)

What problem are you facing?

would be great to add a social image to this repo

What problem are you facing?

@thephred and @negz made great progress on switching to xgql and finished it. Nothing in our setup uses crossplane-graphql anymore.

How could Universal Crossplane help solve your problem?

We can remove it!

In order to increase the likelihood of an organisation feeling comfortable deploying UXP and connecting it to Upbound Cloud we'd like to reduce the permissions required to run UXP. Specifically we'd like to avoid the 'user facing' ClusterRoles installed by the Crossplane Helm chart (e.g. crossplane-admin, crossplane-edit, etc) being granted access to:

• Interacting with namespaces in any way.
• Interact with RBAC types (cluster roles, roles, bindings, etc) in any way.
• Read any secrets.

We would like to allow the "writer" roles (e.g. crossplane-admin and crossplane-edit) to write secrets to a specific namespace, such as upbound-system in order to allow Upbound Cloud to create provider credential secrets if necessary.

In addition to removing these RBAC permissions we'd like to add some:

• All user-facing ClusterRoles (not just crossplane-admin) should have access to get, list, and watch CRDs. Currently crossplane-graphql uses its own permissions to view this type, but xgql instead uses the permissions of the Kubernetes user that calls it per upbound/xgql#9 and https://github.com/upbound/wesaas/issues/794.
• All user-facing ClusterRoles should have access to read the ConfigMap that contains UXP version info per #13. Note that they should have access to read only this ConfigMap (e.g. restricted by resourceName).

It's worth noting that these changes make the crossplane-admin and crossplane-edit roles identical. I don't think we want to fork the actual RBAC manager code (so it will keep creating roles that aggregate up to crossplane-admin and crossplane-edit). We might consider not creating both roles in the Helm chart (e.g. creating only crossplane-admin), but this probably makes a negligible difference.

Note also that at the present time we don't want to make any of these changes in the upstream Crossplane Helm chart, though we may in future.

What problem are you facing?

Currently, the permission level is set in build time due to constraints of not having an operator and we choose edit in build time but that doesn't allow users to install in view mode.

How could Universal Crossplane help solve your problem?

There are a few options:

• Bootstrapper to manage RBAC objects, i.e. ClusterRoleBinding and ClusterRoles that we conditionally deploy.
  • The permission level would be set either on a new configuration CRD or in an existing ConfigMap we have, like the version ConfigMap.
• Have different listings in OperatorHub; Universal Crossplane - Edit, Universal Crossplane - View, Universal Crossplane.
  • Not sure if it'd be allowed and it could be confusing.
• Agent could have a ConfigMap that will allow users to toggle which groups to use.
  • upbound:view and upbound:edit would still be created but users would have the ability to configure which one(s) are allowed to be used through agent configuration.

Per #11

# Don't connect to Upbound Cloud at all
helm install upbound-stable/uxp --set upbound-cloud-connect=None

# Allow Upbound Cloud read-only access
helm install upbound-stable/uxp --set upbound-cloud-connect=View

# Allow Upbound Cloud read-write access
helm install upbound-stable/uxp --set upbound-cloud-connect=Edit

When installing the UXP Helm chart we'd like to offer the installer a choice between the agent not being installed, being able to impersonate the crossplane-view group only, and also being able to impersonate crossplane-admin and/or crossplane-edit (which I believe would be identical once #16 was implemented).

Presumably if the agent was installed with view access only the Upbound Cloud frontend would operate in a "view only" mode for the connected control plane.

There are three primary personas for upbound distro consumers:

1. New user installing for the first time
2. Crossplane user upgrading to upbound distro
3. Upbound distro user connecting to the upbound cloud

We need to determine what functionality for installing and connecting lives in the distro helm chart vs. the up CLI. In addition, we also need to determine what the experience looks like for each of these scenarios when installing from a marketplace (OperatorHub, AWS, etc.).

Prior Art

Up CLI Epic Doc: https://docs.google.com/document/d/1gwwZxG4iR6ncqG3lcHFsC5F5qtRjJ_JOheAFn4P6YDw/edit?usp=sharing
Thread on packaging agent: https://github.com/upbound/wesaas/pull/780#discussion_r592443099

In our OperatorHub artifact, we're not able to do conditional deployments, i.e. we have to deploy all components in all cases. But this causes agent to go into CreateConfigError because token Secret cannot be mounted. This is OK for cases where UXP connects to UbC but not a good experience for folks that don't connect to UbC.

We can create a placeholder Secret and mount it to agent. It'd wait until the file that the Secret is mounted to is non-empty so that installation is declared as completed by OLM. An alternative approach where bootstrapper deploys agent only if the Secret exists is discussed, too, but that approach requires bootstrapper to have Deployment management permissions and a bit more complicated to handle in the short term. If we move towards making bootstrapper an operator, we can reconsider this decision.

What problem are you facing?

They are disabled in #70 because they report NotReady when server is not started, which is what happens when control plane token doesn't exist. But that's a mode we want to support for OLM and Helm installations to complete without the Secret to allow it to be provided later.

How could Universal Crossplane help solve your problem?

We should let bootstrapper create Deployment if the secret is there and re-enable the probes.

What problem are you facing?

Openshift clusters do not like pods that come with their own runAsUser and runAsGroup fields set, which is the case with Crossplane Helm chart and default to that.

How could Universal Crossplane help solve your problem?

We can probably add a --set here when we generate the OLM bundle to set securityContextCrossplane and securityContextRBACManager to nil but needs some testing.

What problem are you facing?

Current readme was just a placeholder. We need a more thorough explanation of what UXP is.

How could Universal Crossplane help solve your problem?

We should revise README.md with the logo or a banner, similar to OSS Crossplane.

Per https://github.com/upbound/wesaas/issues/795 we'd like to ensure the UXP Helm chart can configure the Upbound Agent such that it can impersonate only a fixed set of Kubernetes groups that are known at install time. This means the Upbound Agent and thus Upbound Cloud will not be able to operate on namespaces, because we won't be able to know at install time what namespaces might exist in the future and thus won't know what groups the Agent might need to impersonate to allow access to those namespaces. Therefore we'd like to prevent the RBAC manager from attempting to create and manage RBAC roles for namespaces in order to reduce the amount Crossplane interferes with the RBAC configuration of existing clusters.

The operations currently performed by the local dev script can be made much simpler by using the CLI. We should update it when a build is available.

What happened?

The UXP logo link the README.md points to a page on https://upbound.io that doesn't exist (i.e. https://upbound.io/uxp).

How can we fix it?

Update the link to the desired location.

What problem are you facing?

Currently the manifests for the getting-started package reside in the docs/ directory. However, they are not automatically built and pushed when changes are applied, meaning the manifests could get out of sync with the latest pushed version.

How could Universal Crossplane help solve your problem?

We should build and push this package as part of CI. It may make sense to couple the versioning to that of UXP, since it will always be used in the context of UXP. This is similar to what we do with Crossplane getting started configurations.

Manual building workaround

Using steps from https://cloud.upbound.io/docs/uxp/build-configuration/#build-the-configuration and
https://cloud.upbound.io/docs/upbound-registry/publishing-a-listing/#push-to-your-repository, we can do something like this to manually build the package as a workaround in the meantime:

[email protected]
docker login registry.upbound.io -u ${UBC_EMAIL}

up xpkg build --package-root="./docs/getting-started/configuration"  --name getting-started.xpkg

UBC_ACCOUNT=exampleorg
UBC_REPO=examplerepo
VERSION_TAG=v0.0.1
up xpkg push ${UBC_ACCOUNT}/${UBC_REPO}:${VERSION_TAG} -f ./docs/getting-started/configuration/getting-started.xpkg

What problem are you facing?

The README.md has a < SCREENSHOT GOES HERE > directive but there is no screenshot.

How could Universal Crossplane help solve your problem?

Add the appropriate screenshot.

What problem are you facing?

OperatorHub listing can have a longer description and CRDs can have examples.

How could Universal Crossplane help solve your problem?

We can copy README.md into clusterserviceversion.yaml.tmpl and also fill out metadata.annotations[alm-examples]
in that file.

What happened?

On the control plane, Create New RDS instance is disabled.

How can we reproduce it?

Follow the steps of https://github.com/upbound/universal-crossplane/blob/main/README.md.

What environment did it happen in?

Universal Crossplane version: v0.1.0
Kubernetes version (kubectl version):

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.3", GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"clean", BuildDate:"2020-05-20T12:52:00Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"18+", GitVersion:"v1.18.8-aliyun.1", GitCommit:"2cbb16c", GitTreeState:"", BuildDate:"2021-01-27T02:20:04Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

We are currently using distroless/static:nonroot as the base image for the bootstrapper and agent services. This is subject to the same issues we identified in Crossplane as described here. We should update to using distroless/static as we did in Crossplane.

What happened?

make e2e.run fails if required variables not set.

[universal-crossplane] Running helm upgrade --install with computed parameters...OK
23:13:46 [ OK ] localdev deploy component: universal-crossplane
23:13:47 [ .. ] localdev deploy component: validation
[validation] Loading required images...
[validation] Loading required images...OK
[validation] Running deploy script...
Running validation...
/home/negz/control/universal-crossplane/.work/local/localdev/config/helper.sh: line 4: 1: unbound variable

How can we reproduce it?

Clone the repo, run make e2e.run

What environment did it happen in?

Universal Crossplane version: latest master
Kubernetes version (kubectl version): N/A

Also see #61

Here is some info about getting the product listed: https://docs.aws.amazon.com/marketplace/latest/userguide/container-product-getting-started.html#container-product-load-form

That's the API we need to call from the containers to register usage: https://docs.aws.amazon.com/marketplacemetering/latest/APIReference/API_RegisterUsage.html

There are three levels where we can call this:

• From the container
  • That's the lowest level, requires using a different image specific to the marketplace
• As init/sidecar container
  • We can inject an init or sidecar container to Deployment of components when we build for AWS Marketplace. But that's easy to circumvent though we may not be as worried.
• Pre-install Helm hook
  • We can make Helm continue with the installation only if the registration is completed but that won't allow us to do live metering, which may not be necessary anyway.
  • But I'm a bit wary of using special Helm features in general.
• A component specific to metering
  • We can have a Deployment whose only job is to handle billing/metering stuff and we can reuse it in other marketplaces if needed. But this is also easy to circumvent since it'll probably give thumbs up on a CR or ConfigMap for Crossplane to work. Though we might find more creative solutions like key exchange that might involve changes in images.

What problem are you facing?

Currently, building the OLM bundle is a manual process. While builds should be reproducible from source, we are not currently building until it is actually time to publish a version.

How could Universal Crossplane help solve your problem?

UXP CI pipelines should build and publish OLM bundles alongside other artifacts.

What problem are you facing?

UXP supports configuration for each of its components encompassed by the overall helm chart. It supports all of the values that Crossplane supports, but also additional ones for things like xgql, the agent, and the bootstrapper. However, there is not currently documentation of how these components can be configured.

How could Universal Crossplane help solve your problem?

It would be awesome to have documentation on parameters and what their behavior does like Crossplane has. It might make sense to maintain something like that here, then automatically sync it to the Upbound docs website.

In #30 we address #18 by adding a upbound.controlPlane.permission Helm chart value that allows a platform operator to connect UXP to UBC in 'view-only' mode. View-only UXP control planes run the agent without permissions to impersonate the upbound:edit group, which means that UBC teams and users can only ever have view access.

In the UBC frontend we have a configuration screen that allows org owners to grant teams 'view' or 'edit' access to a particular control plane. Ideally if a UXP control plane were view-only at the RBAC level we'd prevent UBC from granting a team 'edit' access to that control plane per discussion in https://github.com/upbound/upbound-frontend/issues/1994.

Currently the front-end has no way of knowing whether a control plane is read-only. It can't see what RBAC roles and bindings exist because it doesn't have RBAC access to view those roles and bindings - we don't want to ask cluster operators for that level of access. Given that UXP is the 'source of truth' here it may make sense to expose whether a control plane is currently 'view-only' or through some more scoped mechanism - perhaps a well know ConfigMap?