JFrog Crossplane Kinds Reference

The JFrog Crossplane providers support 260 Kinds. This page explains how to read a Kind entry and how to explore fields from your cluster. It then lists every Kind by provider and API group, with a link to the page that documents it.

How to Read a Kind Entry

The four provider reference pages list every Kind, grouped by provider and API group. Each entry contains the following:

• Summary: What the Kind manages.
• kubectl: The fully-qualified resource name (<plural>.<group>), which also shows the API group. The apiVersion is <group>/v1alpha1. The legacy cluster-scoped variant drops .m from the group.
• Identifier: How the managed resource maps to the JFrog object. For more information, see How the JFrog Crossplane Providers Work.
• Upstream: The JFrog Terraform resource that the Kind is built from. Its upstream documentation describes each field in detail. Field names there are snake_case.
• Fields: The top-level spec.forProvider fields. You must set required fields in forProvider or initProvider.
• Immutable, References, and Secrets, followed by caveats specific to the Kind.

Repository Kinds share most fields. For this reason, the provider reference pages document them per class (local, remote, virtual, federated). Each class documents the common fields once, then only the additional fields of each package type.

Explore Fields from the Cluster

The CustomResourceDefinitions (CRDs) installed in your cluster carry the full schema. The schema includes nested fields, types, allowed values, and descriptions. To explore it, run commands such as the following:

kubectl explain localdockerv2repositories.repository.artifactory.m.crossplane.io.spec.forProvider --recursive
kubectl explain securitypolicies.policy.xray.m.crossplane.io.spec.forProvider.rule.actions
kubectl get crds | grep -E '(artifactory|xray|project|platform)\.m\.crossplane\.io'

Manifest Skeleton

Every managed resource follows this skeleton:

apiVersion: <group>/v1alpha1
kind: <Kind>
metadata:
  name: <name>                     # usually the JFrog identifier
  namespace: team-a
  # annotations: {crossplane.io/external-name: <identifier if it differs from metadata.name>}
spec:
  providerConfigRef: {kind: ClusterProviderConfig, name: jfrog}
  # managementPolicies: ["*"]
  forProvider: {}                  # required fields go here (or in initProvider)
  # initProvider: {}               # values applied only at creation

In most Kinds, nested blocks that appear once are written as one-element YAML lists, for example adminPrivileges: [{...}] or blockDownload: [{...}]. kubectl explain shows <[]Object> for these blocks.

Kinds by Provider

The following table shows the number of Kinds for each provider and the page that documents them.

Artifactory Kinds

The Artifactory Provider Kinds page documents all Artifactory Kinds.

Xray Kinds

The Xray Provider Kinds page documents all Xray Kinds.

Project Kinds

The Project Provider Kinds page documents all Project Kinds.

Platform Kinds

The Platform Provider Kinds page documents all Platform Kinds.

Several providers share short Kind names, such as Group, User, Permission, Role, Repository, and Webhook. Use fully-qualified names with kubectl to avoid this ambiguity.

Next Steps

• To look up a Kind, open its provider page: Artifactory Provider Kinds, Xray Provider Kinds, Project Provider Kinds, or Platform Provider Kinds.
• To learn how identifiers work, see How the JFrog Crossplane Providers Work. To learn how references and secrets work, see Reference Other Managed Resources and Pass Secret Values.
• To create, update, adopt, and delete JFrog objects, see Manage JFrog Objects with Crossplane.