#Feature Flags

Connectors uses feature flags to control optional or gradually introduced capabilities. The flags are stored in the connectors-config ConfigMap created by the ConnectorsCore component.

This page describes the feature flags currently defined for the ConnectorsCore component.

#Where Feature Flags Are Stored

The ConnectorsCore component creates a connectors-config ConfigMap in the namespace where the component is installed. The default namespace is connectors-system.

apiVersion: v1
kind: ConfigMap
metadata:
  name: connectors-config
  namespace: connectors-system # example namespace
data:
  enable-connector-apis-permissions: "false"
  enable-connector-apis-write-passthrough: "false"
  enable-connector-proxy-permissions: "false"
  enable-connectors-approval: "false"
  enable-multi-connector: "false"
  enable-custom-ca-certs: "false"
  enable-pod-image-pull-via-connector: "false"

All values are string booleans ("true" or "false"). Because the flags are stored in one shared ConfigMap, they apply to the current Connectors installation rather than to a single Connector.

#View Current Feature Flags

You can inspect the ConfigMap directly:

kubectl -n <connectors-namespace> get configmap connectors-config -o yaml

You can also query the Connectors Operator API:

curl -H "Authorization: Bearer ${K8S_TOKEN}" \
  "https://platform.example.com/clusters-rewrite/${CLUSTER_NAME}/connectors-operator/featureflags"

This API requires permission to access ConnectorClass. For the endpoint details, see Connector API.

#Update a Feature Flag

Feature flags are configured through ConnectorsConfig.spec.components.core.spec.featureFlags. The Connectors Operator propagates the value through the managed ConnectorsCore child CR, which merges it into the connectors-config ConfigMap during reconciliation. CR values override manifest defaults.

#Via ConnectorsConfig (Recommended)

Edit the cluster-singleton ConnectorsConfig to set feature flags declaratively:

kubectl edit connectorsconfig connectors-config -n connectors-operator

apiVersion: operator.connectors.alauda.io/v1alpha1
kind: ConnectorsConfig
metadata:
  name: connectors-config
spec:
  components:
    core:
      spec:
        featureFlags:
          enable-multi-connector: "true"
          enable-custom-ca-certs: "true"

Or use kubectl patch:

kubectl patch connectorsconfig connectors-config -n connectors-operator --type merge \
  -p '{"spec":{"components":{"core":{"spec":{"featureFlags":{"enable-multi-connector":"true"}}}}}}'

Feature flags declared here override the manifest defaults in connectors-config. Keys not listed keep their manifest default values. When a new version introduces additional feature flags, they appear automatically with their default values.

Note: Do not edit the managed ConnectorsCore child CR or the connectors-config ConfigMap directly — both are reconciled back from ConnectorsConfig on the next reconcile. Always update ConnectorsConfig.spec.components.core.spec.featureFlags.

#Built-in Feature Flags

#Feature Flag Details

#enable-connector-apis-permissions

When this flag is enabled, the system applies RBAC-based permission checks to access performed through the Connectors API. This separates the permission to read a Connector resource from the permission to use that Connector to access the target tool API.

This capability is useful when you want users or workloads to discover Connectors but still control whether they can perform read or write operations against the integrated tool.

Related reading:

• Connectors Permission Model
• Connector API
• Connector Resource Levels and Permissions

#enable-connector-apis-write-passthrough

When this flag is enabled, the Connectors API gateway accepts write methods (POST, PUT, DELETE, PATCH) and forwards them to the target tool. When the flag is disabled (the default), write requests are rejected with HTTP 405 Method Not Allowed. Read methods (GET, HEAD, OPTIONS) are accepted regardless of this flag.

For the full behavior — HTTP method to Kubernetes verb mapping, RBAC examples, and the interaction with enable-connector-apis-permissions — see Connector API › Write methods (passthrough).

#enable-connector-proxy-permissions

When this flag is enabled, permission control is applied to requests handled through Connectors Proxy. This is relevant when workloads or tools access external systems through proxy-based secretless connectivity.

Use this flag when proxy access itself must be governed by platform permissions. This flag is also required when enable-connectors-approval is enabled, because the approval feature protects the use of Connectors Proxy.

Related reading:

• Connectors Permission Model
• Connectors Proxy
• Connectors CSI Driver
• Release Notes

#enable-connectors-approval

When this flag is enabled, Connectors can participate in approval-gated access workflows for Connectors Proxy. This feature is intended to protect proxy-based connector usage, especially when workloads access external tools through proxy endpoints.

Enable enable-connector-proxy-permissions together with this flag. Without proxy permission control, the approval feature cannot protect the target proxy usage path.

This feature is designed for scenarios such as production artifact promotion, deployment to protected clusters, or any environment where proxy-based connector usage must be approved before access is granted.

Related reading:

• Connectors Permission Model
• Connectors Approval & Permission Gating
• Connectors Proxy
• Connectors CSI Driver

#enable-multi-connector

When this flag is enabled, the Connectors CSI Driver can mount configuration rendered from multiple Connectors in a single volume. This allows one workload to consume multiple tool integrations together, and the driver merges rendered configuration according to the configured configuration.names.

This is useful for workflows such as a Tekton task that needs one Connector for reading dependencies and another Connector for publishing artifacts.

Related reading:

• Multiple Connectors in Connectors CSI
• Using Maven Connector in Tekton Task

#enable-custom-ca-certs

When this flag is enabled, the platform trusts additional CA certificates when verifying TLS connections to tools, without disabling certificate verification. The trust pool is composed additively:

1. System default CA pool — the OS-level trust store baked into the container image.
2. Global custom CA certificates — Secrets in the connectors-system namespace labeled connectors.cpaas.io/ca-cert: "true".
3. Per-Connector CA certificate — an optional Secret referenced by spec.caCertSecretRef.name on the Connector, which must reside in the same namespace as the Connector.

The constructed CA pool is used by controller liveness and authentication probes, Connectors Proxy traffic, ConnectorClass accessibility checks, and extension proxies (OCI, Harbor, Git HTTPS, etc.) where applicable.

When the flag is enabled, the informational CACertReady condition is published on each Connector to reflect the per-Connector CA load status. This condition has severity: Info and does not affect the top-level Ready condition.

Related reading:

• Configure Custom CA Certificates
• Connector concepts: Custom CA Certificates

#enable-pod-image-pull-via-connector

When this flag is enabled, the OCI and Harbor Connector PodWebhooks rewrite Pod container image addresses to the Connector Proxy URL when the Pod has the connectors.cpaas.io/connector: <namespace>/<connector-name> annotation. The kubelet then pulls images through the Connector Proxy using a ServiceAccount-token-based imagePullSecret, so long-term registry credentials do not need to be distributed to user namespaces.

When the flag is disabled (the default), the PodWebhook rejects Pod creation requests that carry the connectors.cpaas.io/connector annotation, with an error message pointing to this flag and the ConnectorsConfig.spec.components.core.spec.featureFlags field for enabling it. Pods without that annotation are unaffected, and existing manual imagePullSecrets workflows continue to work normally.

Related reading:

• Using OCI Connector to Deploy Workloads
• Using Harbor Connector to Deploy Workloads

#Next Steps

• Connector API
• Connectors Proxy
• Connectors CSI Driver
• Feature Maturity