What problem are you facing?
When using the Crossplane CLI in corporate environments, we often have to interact with private OCI registries secured by a custom Enterprise Certificate Authority (CA) to pull or push Crossplane Packages (.xpkg).
When bootstrapping local development environments (especially when tools wrap KinD under the hood using container runtimes like Colima or Podman), the Crossplane Package Manager pod fails to pull packages because it does not trust the private registry's CA.
Currently, there is no native way to pass a custom CA or a default KinD configuration through the Crossplane CLI. Users are forced to rely on brittle post-installation workarounds, such as shell wrappers or running automated scripts (kubectl create secret + kubectl patch deployment crossplane to mount the CA) right after the local cluster "pops". This creates friction and hurts the local Developer Experience (DX), especially when dealing with the specific file-sharing and permission constraints of Colima and Podman.
How could Crossplane help solve your problem?
Crossplane could solve this by allowing users to inject custom CAs and local environment configurations natively through the CLI. We envision two possible approaches:
- A Global CLI Configuration File: Support a global file (e.g.,
~/.crossplane/config.yaml) where users can define a default path for custom CAs or a default KinD configuration override. This would be automatically applied whenever a local environment lifecycle is managed by the CLI.
- Dedicated CLI Flags: Add explicit flags to local/init commands, such as:
--ca-cert-path=/path/to/enterprise-ca.crt: This would automatically handle creating the Kubernetes Secret and patching the Crossplane deployment to mount the CA in the appropriate trust store path.--kind-config=/path/to/custom-kind.yaml: This would allow users to pass advanced mounting options, which is crucial for mapping local certificate directories when using Colima or Podman.
What problem are you facing?
When using the Crossplane CLI in corporate environments, we often have to interact with private OCI registries secured by a custom Enterprise Certificate Authority (CA) to pull or push Crossplane Packages (
.xpkg).When bootstrapping local development environments (especially when tools wrap KinD under the hood using container runtimes like Colima or Podman), the Crossplane Package Manager pod fails to pull packages because it does not trust the private registry's CA.
Currently, there is no native way to pass a custom CA or a default KinD configuration through the Crossplane CLI. Users are forced to rely on brittle post-installation workarounds, such as shell wrappers or running automated scripts (
kubectl create secret+kubectl patch deployment crossplaneto mount the CA) right after the local cluster "pops". This creates friction and hurts the local Developer Experience (DX), especially when dealing with the specific file-sharing and permission constraints of Colima and Podman.How could Crossplane help solve your problem?
Crossplane could solve this by allowing users to inject custom CAs and local environment configurations natively through the CLI. We envision two possible approaches:
~/.crossplane/config.yaml) where users can define a default path for custom CAs or a default KinD configuration override. This would be automatically applied whenever a local environment lifecycle is managed by the CLI.--ca-cert-path=/path/to/enterprise-ca.crt: This would automatically handle creating the Kubernetes Secret and patching the Crossplane deployment to mount the CA in the appropriate trust store path.--kind-config=/path/to/custom-kind.yaml: This would allow users to pass advanced mounting options, which is crucial for mapping local certificate directories when using Colima or Podman.