Automated Crossplane Providers From OpenAPI Specs

Nov 5, 2025 by SLV Team 50 views

Automated Crossplane Providers: Revolutionizing Kubernetes Infrastructure Management

Automated Crossplane providers represent a significant leap forward in Kubernetes-native infrastructure management. This article delves into the potential of generating production-quality Crossplane providers directly from OpenAPI specifications. Imagine the ability to quickly and consistently integrate any REST API into your Kubernetes environment, enabling seamless infrastructure-as-code workflows. This is the promise of automated provider generation. This approach streamlines the process, reduces manual effort, and ensures that your infrastructure definitions stay in sync with the latest API updates. We'll explore the advantages, technical aspects, and future possibilities of this exciting technology.

Why Automate Provider Creation?

Creating Crossplane providers manually is a time-consuming and often complex process. Each provider requires deep understanding of the target API, familiarity with Crossplane development best practices, and meticulous coding to ensure reliability and maintainability. Automating this process offers several compelling benefits, including a reduced time-to-market for new providers, which means you can integrate new APIs into your Kubernetes infrastructure more quickly. It also guarantees consistency between the API and its Crossplane representation, minimizing the risk of errors and ensuring accurate resource management. Furthermore, automatic updates to providers become possible when APIs evolve, reducing the maintenance burden and preventing your infrastructure definitions from becoming outdated. And finally, automating provider creation lowers the barriers to entry for anyone looking to build Crossplane providers. The end result is production-quality providers that align with hand-written code standards.

Quality Requirements for Generated Providers

The goal of this initiative is to create providers that are not only functional but also meet the high standards of production environments. These generated providers must be production-ready, meaning they are stable, reliable, and suitable for deployment in the Crossplane Registry. They must also be idiomatic, meaning they follow the conventions and best practices of the Go programming language, as well as the patterns used by Crossplane and Kubernetes. The generated code should be indistinguishable from hand-written code, without obvious artifacts that expose the code generation process. This means maintaining the same level of quality and readability that you would expect from manually crafted providers. Generated providers need to adhere to all Crossplane provider development guidelines, using modern tooling like the latest versions of crossplane-runtime and controller-runtime. They also need to include extensive test coverage, with thorough tests built using controller-runtime testing frameworks. Well-documented CRDs (Custom Resource Definitions) and clear examples should be provided to assist users in understanding how to use and customize the providers. Full Kubernetes-native integration is also required, ensuring smooth integration with tools such as kubectl, GitOps workflows, and the broader Kubernetes ecosystem.

Deep Dive into the Proposed Solution

Let's get into the specifics of how this automated provider generation will work. The proposed solution involves generating Crossplane providers that leverage existing generated Go client SDKs. This ensures compatibility and allows us to leverage the API client's existing functionality. Crossplane-runtime will be used for managing resource reconciliation, ensuring that the desired state of the managed resources is always reflected in the external infrastructure. Furthermore, controller-runtime will be used to implement Kubernetes controller patterns, allowing the providers to be seamlessly integrated into the Kubernetes control plane. They will be generated with idiomatic Go code that adheres to Crossplane’s standards and best practices, making the resulting providers easy to read, maintain, and extend. The solution will support managed resources with clear CRUD (Create, Read, Update, Delete) operation mapping, allowing for precise control over the external resources. Authentication will be handled using the API’s security schemes, ensuring that access to external resources is properly secured. Comprehensive testing with controller-runtime will be included to ensure that the generated providers are reliable and robust. CRDs will be generated from Go structs using controller-gen, simplifying the process of creating custom resource definitions. Crossplane compositions and XRDs (Crossplane Resource Definitions) will also be supported, enabling the creation of complex infrastructure stacks. Complete package metadata, including a crossplane.yaml file, will be included, allowing users to easily install and manage the providers. Finally, modern build tooling, such as GoReleaser, Makefiles, and GitHub Actions, will be utilized to automate the build, testing, and deployment processes. Extensive customization will be supported through the use of vendor extensions, giving users the flexibility to customize the generated providers to meet their specific needs.

Understanding the Command Structure and YAML Configuration

To make this process as easy as possible, we envision a simple command-line interface. Let's take a look at the proposed command structure. To generate a Crossplane provider, you would use a command similar to this: og generate openapi.yaml --type crossplane -o ./provider-myapi --option sdkPackage=github.com/example/myapi-go-sdk. Alternatively, you can use a configuration file, such as og.yaml, which allows for a more declarative approach. This file specifies the OpenAPI specification to use, the output directory for the generated provider, and other configuration options. Here's an example of an og.yaml file:

spec: openapi.yaml
output:
 base: ./generated
targets:
  - type: client
    language: go
    output: go-sdk
    options:
      package_name: myapi
  - type: crossplane
    language: go
    output: provider-myapi
    options:
      provider_name: myapi
      sdk_package: github.com/example/myapi-go-sdk
      sdk_path: ../go-sdk
      group: myapi.example.com
      version: v1alpha1

This configuration file first generates a Go client SDK from the OpenAPI specification and then generates the Crossplane provider itself. This allows you to define the behavior of the generated provider, including the provider's name, the SDK package, the API group, and the API version.

The Architecture and Its Components

The generated provider will follow Crossplane's best practices, ensuring that it is well-structured and easy to maintain. The directory structure will look similar to this:

provider-myapi/
├── cmd/
│   └── provider/
│       └── main.go                  # Provider entry point
├── apis/
│   ├── v1alpha1/                    # API version
│   │   ├── doc.go                   # Package docs
│   │   ├── groupversion_info.go     # GVK definitions
│   │   ├── register.go              # Scheme registration
│   │   ├── database_types.go        # Database managed resource
│   │   ├── user_types.go            # User managed resource
│   │   ├── zz_generated.deepcopy.go # Auto-generated
│   │   └── zz_generated.managed.go  # Auto-generated
│   └── v1beta1/                     # Future API versions
├── internal/
│   ├── controller/
│   │   ├── database/
│   │   │   ├── database.go          # Database controller
│   │   │   └── database_test.go
│   │   ├── user/
│   │   │   ├── user.go              # User controller
│   │   │   └── user_test.go
│   │   └── setup.go                 # Controller registration
│   └── clients/
│       └── myapi.go                 # Client factory
├── package/
│   ├── crossplane.yaml              # Provider package metadata
│   └── crds/
│       ├── myapi.example.com_databases.yaml
│       └── myapi.example.com_users.yaml
├── examples/
│   ├── providerconfig.yaml          # Provider configuration
│   ├── database/
│   │   ├── database.yaml            # Database example
│   │   └── kustomization.yaml
│   └── user/
│       ├── user.yaml                # User example
│       └── kustomization.yaml
├── cluster/
│   └── images/
│       └── provider-myapi/
│           └── Dockerfile           # Provider image
├── .github/
│   └── workflows/
│       ├── ci.yml                   # Build, test, lint
│       ├── release.yml              # GoReleaser
│       └── promote.yml              # Package promotion
├── .golangci.yml                    # Linting configuration
├── Makefile                         # Build automation
├── go.mod
├── go.sum
├── PROJECT                          # Kubebuilder metadata
├── README.md                        # Comprehensive documentation
├── CHANGELOG.md                     # Semantic versioning changelog
├── LICENSE                          # License file
└── .gitignore

This structure ensures that the provider is organized and follows the recommended best practices. The cmd directory contains the main entry point for the provider. The apis directory contains the API types, including the database and user types. The internal directory contains the controller implementations and the client factory. The package directory contains the package metadata and the generated CRDs. The examples directory contains example resources and configuration files. This well-defined structure will allow you to quickly understand and manage the generated provider.

Vendor Extensions: Customizing the Provider

Vendor extensions are a key feature of this system, providing fine-grained control over the generation process. These extensions allow you to customize the behavior of the generated provider to match the specific needs of your API. The following extensions are available:

Resource Definition Extensions

x-crossplane-resource: <name>: Declares an operation as part of a Crossplane managed resource.
x-crossplane-resource-action: <create|observe|update|delete>: Maps operation to controller action.
x-crossplane-name: <name>: Override the generated resource/field name.
x-crossplane-description: <description>: Override OpenAPI description with Kubernetes-friendly text.

Field Configuration Extensions

x-crossplane-external-name: <boolean>: Mark field as the external resource identifier.
x-crossplane-status: <boolean>: Mark field as status (output-only).
x-crossplane-spec: <boolean>: Mark field as spec (input).
x-crossplane-required: <boolean>: Mark field as required in Spec.
x-crossplane-optional: <boolean>: Mark field as optional.
x-crossplane-immutable: <boolean>: Mark field as immutable.
x-crossplane-reference: <object>: Configure cross-resource references.
x-crossplane-sensitive: <boolean>: Mark field as sensitive (stored in connection secret).
x-crossplane-default: <value>: Default value for field.
x-crossplane-validation: <object>: Kubebuilder validation markers.
x-crossplane-print-column: <object>: Add field as additional printer column in kubectl output.

Provider Configuration Extensions

x-crossplane-group: <name>: Set API group for CRDs.
x-crossplane-version: <version>: Set API version.
x-crossplane-short-names: <array>: Define short names for kubectl.
x-crossplane-categories: <array>: Add resource to kubectl categories.

Connection Secret Extensions

x-crossplane-connection-secret: <object>: Configure which fields to publish to connection secret.

Composition Extensions

x-crossplane-composite: <boolean>: Mark resource as composite resource (XR).
x-crossplane-claim: <object>: Define claim (XRC) for the composite resource.

Late Initialization Extensions

x-crossplane-late-init: <boolean>: Enable late initialization for field.

Documentation Extensions

x-crossplane-example: <value>: Example value for CRD documentation.
x-crossplane-example-yaml: <string>: Complete YAML example for documentation.
x-crossplane-notes: <string>: Additional notes for CRD documentation.

Policy Extensions

x-crossplane-deletion-policy: <Orphan|Delete>: Default deletion policy for the resource.
x-crossplane-management-policy: <FullControl|ObserveOnly|OrphanOnDelete>: Default management policy.

Controller Extensions

x-crossplane-external-name-from: <field>: Field to use for external-name annotation.
x-crossplane-import: <object>: Configure resource import.

These extensions give you immense power to tailor the generated provider to the specifics of your API, ensuring that you can control every aspect of the infrastructure management process.

Validation Rules and Provider Implementation Details

The generator is designed with rigorous validation rules to ensure the quality and consistency of the generated providers. It validates that all required operations are present, that actions are unique, and that naming conventions are consistent. The generator also validates that all resources have an external name field, that fields are correctly separated between Spec and Status, and that API groups and resource kinds follow the correct format. Furthermore, the generator ensures that Kubebuilder markers are valid, that references are correctly defined, and that connection secrets are linked to existing status fields. Fields marked as immutable are also checked to ensure that they are in the Spec, and that the Print Columns point to existing fields. All these tests will help you build reliable and maintainable providers.

Main Entry Point and API Types

The main entry point for the generated provider is in cmd/provider/main.go. This file sets up the controller manager, registers the controllers, and starts the manager. The API types are defined in apis/v1alpha1/database_types.go. This file defines the DatabaseParameters, DatabaseObservation, DatabaseSpec, and DatabaseStatus structs. The Database struct is the managed resource that represents a cloud database instance. The controller implementation is in internal/controller/database/database.go. This file contains the Setup function, which adds a controller that reconciles Database managed resources. The connector and external structs implement the managed.ExternalClient interface, which is used to interact with the external API.

The Benefits and Use Cases

The benefits of automatically generating Crossplane providers are extensive. You can expect Kubernetes-native resource management, a declarative API that simplifies infrastructure definition, and seamless cross-resource references for complex resource relationships. Automatic management of connection secrets, the ability to build compositions and GitOps-friendly workflows, and the integration of Kubernetes-native access control are all included. This technology enables multi-cluster management capabilities, providing a robust solution for managing infrastructure across multiple environments. The use cases for this technology are varied and include the streamlined management of cloud infrastructure through Kubernetes, the development of internal platform APIs with a Kubernetes-native user experience, the creation of self-service infrastructure catalogs, the seamless enablement of GitOps workflows for any REST API, and the effortless integration of external services into your Kubernetes control plane. It also opens the door to creating sophisticated composite resources from multiple APIs and constructing platform engineering initiatives and golden paths.

A Glimpse into the Future Enhancements

In the future, we plan to enhance this technology even further. We'll add support for Composite Resources (XRs) and Claims (XRCs), automatic composition generation, and EnvironmentConfig support. We're also considering deploymentRuntimeConfig generation, Function support (Composition Functions), and integration with the Upbound Marketplace. Automatic version management, enhanced OpenAPI extension support, and test generation with controller-runtime are also planned. Observability integration, admission webhooks, and conversion webhooks for version migration are also in our sights.

Implementation Roadmap

To achieve these goals, we will follow a phased approach. The first phase involves generating the core provider structure, managed resource types, and controller scaffolding. Then we move on to advanced resource features such as external name handling, references, and connection secret publishing. Further integration will involve adding Kubebuilder markers, print columns, RBAC generation, and example resource generation. Finally, we will add support for Composition, XR generation, and environment configuration.

Conclusion

Automated Crossplane provider generation from OpenAPI specifications is a powerful and efficient way to manage infrastructure. This allows you to integrate any REST API into your Kubernetes environment with minimal effort. This will streamline the development of custom infrastructure integrations, and enable GitOps workflows for any REST API, and increase the flexibility of your Kubernetes environment. With its comprehensive features, benefits, and planned enhancements, this technology promises to transform how we manage infrastructure in the cloud-native era. This approach makes it easier to build and deploy applications, and simplifies the management of complex cloud infrastructure. The future is bright for this innovative technology, which will surely play a vital role in cloud-native infrastructure management.