ConnectorClass
TOC
Overview
ConnectorClass is a cluster-level resource that defines the access modes and behavior specifications for specific types of tools. It describes:
- The format of the tool's access address
- Supported authentication methods
- The method for checking tool availability
- The method for verifying authentication validity
- The API address of the tool
For example, the following definition describes a Git type connector that supports basic authentication:
Address Information
Address information defines the format for accessing the tool. Currently, string-type address configurations are supported. This address information restricts the field type constraints that the current type of tool must meet.
At this point, it indicates that the address information for connecting the tool to the platform must be of string type.
Authentication Information
Authentication Type
The authentication type defines the type of credentials used for tool authentication. A tool can support multiple authentication types, allowing users to choose one when using the tool.
Users can uniquely name the current authentication type via
spec.auth.types[].name, which must be unique and cannot be repeated.spec.auth.types[].secretType, which specifies the type ofSecretneeded for authentication, corresponding to akubernetes secret type.
Example:
Authentication Parameters
Parameters required for credentials during authentication are defined by spec.auth.types[].params.
For standard Kubernetes secret types with clearly defined data fields, parameters can be omitted. For example:
kubernetes.io/basic-auth: username and password authenticationkubernetes.io/ssh-auth: SSH key authentication
For custom authentication types, the required authentication parameters can be defined, and at this point, the secretType is marked as kubernetes.io/opaque.
For example, for GitLab's Personal Access Token (PAT) authentication:
At this point, it will require that the credentials used in the tool connector include username and private-token information.
Optional Authentication
Some tools support access without authentication, marked by the optional field indicating whether authentication is optional:
For example, the following indicates that credentials for basicAuth are optional while sshAuth credentials are mandatory.
At this point, when connecting this type of tool to the platform, the basicAuth type of authentication can be omitted.
Accessibility Check
Accessibility checks are used to verify if the tool can be accessed normally. The configuration of how this type is conducted is done through the livenessProbe field.
For example, the following snippet indicates that detection is performed using HTTP requests.
When the tool returns a 200 status, it is considered accessible.
Authentication Checking
Authentication checking is used to verify how the validity of the authentication information for tools of this type is checked.
For example, the following YAML indicates that during the authentication check of the tool, an http GET request will be initiated with the injected Authorization: abc header.
authNameindicates the authentication type being used, needing to align withspec.auth.types[].name.- During the authentication check, the address information of the connector tool will be directly used.
spec.authProbes[].probe.http.methodspecifies the HTTP method used for authentication, supporting GET and POST. Defaults to GET.spec.authProbes[].probe.http.disableRedirectspecifies whether to disable redirection during authentication. Defaults to allow automatic redirection.
Custom Authentication Check Parameters
Some authentication checks may require additional parameters, such as specifying the repository name when checking access to a Git repository. These can be specified via spec.authProbes[].params.
Authentication Check Expressions
When configuring authProbes, expressions can dynamically obtain credential information or Connector information.
For example,
- Expressions can be used in
httpHeadersandpathfields. - The expression format is go template
- Supported top-level fields are:
.Connector: The information of the Connector itself.Secret: The Secret information used for Connector data.
- The methods available within expressions can be referenced in the sprig documentation
- For example:
b64enc: Base64 encoding for strings,trimPrefixto remove string prefixes
- For example:
Example
Basic Auth authentication checking
The connector will perform validity checks based on the information in the ConnectorClass.
The above yaml indicates the authentication checking for basic auth:
path: Utilizes therepositoryvalue set inauth.paramswithin theConnectorinformation, concatenated as/<repository>/info/refs?service=git-upload-packAuthorization: If the Connector is configured with a Secret, theusernameandpasswordfields from the Secret will be returned in base64.
ConnectorClass API {connectorclass_api}
The ConnectorClass can provide a RESTful API for the current ConnectorClass, making it easier for clients to access the resources within tools when using Connectors.
ConnectorClass API needs to be configured in the spec.api field, such as:
You can specify the Service information of the API via spec.api.ref. If the API address of ConnectorClass has a fixed prefix, you can specify it using spec.api.uri. For example:
Alternatively, you can specify the absolute path of the API using spec.api.uri. For example:
Regardless of the form, the final resolved API address will be stored in status.api.address.url. For instance:
To specify the connector class API through a service
To specify the connector class API via URI
To specify the connector class API through service while using spec.api.uri to specify the API path
For more details, refer to
Configurations
You can specify configuration information through spec.configurations. For example:
Typically, we can specify a certain configuration information for a type of tool to facilitate configuration during use. For example:
- For
gittype tools, provide the configuration for.gitconfig - For
oci registrytype tools, provide the configuration forconfig.json
These configuration pieces can be mounted to Pods in file form through the connectors-cs-driver.
The configuration contents support using variables, which can be dynamically rendered during mounting. For specifics, refer to the description of "Configuration file rendering" in connectors-cs-driver.
Example
The following ConnectorClass provides a file named .gitconfig, used to ignore SSL certificate verification during git clone.
The following ConnectorClass provides a file named .gitconfig that automatically injects headers and replaces the Git URL during git clone.
More Information
Metadata
ConnectorClass is a standard k8s resource that can be tagged with custom information through labels and annotations.
For example:
Status Information
Condition information will be stored in status.conditions. The types include:
APIReady: Status information of the API capabilityProxyReady: Status information of the Proxy capabilityReady: Indicates the overall status of the current ConnectorClass
Ready Condition
The Ready Condition is used to indicate the current status of the ConnectorClass. It aggregates the status of other conditions.
When all other conditions are True, the current condition is True. When any other condition is False, the current condition is False. When any other condition is Unknown, the current condition is Unknown.
APIReady Condition
Indicates the status information of the API service configured for the ConnectorClass. The API service is specified through spec.api of the ConnectorClass.
Note:
- The API detection only attempts to request the link without checking any HTTP return value. Health checks for the API service should rely on the API service's own health check mechanism.
- Due to the potential for external services to change at any time, the API's status information cannot represent real-time information. It is recommended that clients use this status information merely as a prompt and not rely on it to block client actions.
ProxyReady Condition
Indicates the status information of the Proxy service configured for the ConnectorClass. The Proxy service is specified through spec.proxy of the ConnectorClass.
Compatibility
Updates to the ConnectorClass may impact existing Connectors. If there are incompatible changes to the ConnectorClass, it may cause previously created Connectors to become invalid. The following are some changes that may lead to incompatibility:
-
Changes to authentication information: If the ConnectorClass modifies supported authentication types or methods, it may cause Connectors using the old authentication method to fail to function properly.
-
Changes to configuration information: If there are changes to the configuration information of the ConnectorClass, such as removing an existing configuration, it may lead to Kubernetes workloads relying on the old configuration failing to work.
It is recommended to assess the scope of impact before updating the ConnectorClass, or if necessary, create a new ConnectorClass.
More Examples
-
ConnectorClass supporting
basic-authauthentication type -
ConnectorClass simultaneously supporting both
basic-authandssh-authauthentication types, withbasic-authhaving optional authentication information. -
ConnectorClass for a custom authentication type
-
ConnectorClass configured with a
liveness probe -
ConnectorClass configured with an
auth probe -
Complete Git connector configuration example: