Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 8 additions & 5 deletions docs/content/developers/dev-environments.md
Original file line number Diff line number Diff line change
Expand Up @@ -156,11 +156,14 @@ All the instructions assume you have already cloned the kube-bind repository and
=== "Kind"

This guide will walk you through setting up kube-bind between two Kubernetes clusters, where

* **Provider cluster**:

* Deploys kube-bind/backend
* Provides kube-bind compatible backend for Sheriffs resources

* **Consumer cluster**:

* Provides an application consuming Sheriffs and Cowboys resources from the Provider cluster

This guide works best on Linux. macOS and Windows users may need to adjust some commands accordingly.
Expand Down Expand Up @@ -244,7 +247,7 @@ All the instructions assume you have already cloned the kube-bind repository and
```

Now in the consumer cluster you should see these CRDs:

```bash
kubectl get crd 10:10:56
NAME CREATED AT
Expand All @@ -255,13 +258,13 @@ All the instructions assume you have already cloned the kube-bind repository and
Try creating an example MangoDB resource and observe it being synced to provider clusters:

```bash
kubectl bind dev example | kubectl create -f -
KUBECONFIG=kind-consumer.kubeconfig kubectl get mangodbs.mangodb.com
KUBECONFIG=kind-provider.kubeconfig kubectl get mangodbs.mangodb.com
kubectl bind dev example | kubectl create -f -
KUBECONFIG=kind-consumer.kubeconfig kubectl get mangodbs.mangodb.com
KUBECONFIG=kind-provider.kubeconfig kubectl get mangodbs.mangodb.com
```

## Cleanup

```sh
kind bind dev delete
```
81 changes: 42 additions & 39 deletions docs/content/usage/api-concepts.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,8 +17,8 @@ kube-bind uses several specialized Kubernetes custom resources to orchestrate th

**Purpose**: Defines a reusable template for exporting a group of related APIs and their permission requirements.

**Used by**: Service providers
**Scope**: Cluster-scoped
**Used by**: Service providers
**Scope**: Cluster-scoped
**Lifecycle**: Long-lived template definition

### Key Features
Expand All @@ -38,16 +38,16 @@ metadata:
spec:
scope: Cluster # or Namespace
description: "A comprehensive service template"

# Core APIs being exported
resources:
- group: example.com
resource: widgets
versions: ["v1", "v1alpha1"]
- group: example.com
- group: example.com
resource: gadgets
versions: ["v1"]

# Additional resources the service needs access to
permissionClaims:
- group: ""
Expand All @@ -62,7 +62,7 @@ spec:
jsonPath:
name: spec.secretRef.name
namespace: spec.secretRef.namespace

# Pre-created namespaces for this service. These will be owned by provider (service owned).
namespaces:
- name: my-service-system
Expand All @@ -74,12 +74,12 @@ spec:
- **Template**: The definition (APIServiceExportTemplate) - shared and reusable
- **Instance**: The actual export (APIServiceExport) - created per binding

## APIServiceExport
## APIServiceExport

**Purpose**: Represents an active, instantiated export of a specific set of CRD's and permission claims to consumer clusters.

**Used by**: Automatically created by konnector agents
**Scope**: Namespaced
**Used by**: Automatically created by konnector agents
**Scope**: Namespaced
**Lifecycle**: Created when consumers bind to templates

### Key Features
Expand All @@ -102,7 +102,7 @@ spec:
- group: example.com
resource: widgets
versions: ["v1"]

# Permission claims for this specific export
permissionClaims:
- group: ""
Expand All @@ -112,7 +112,7 @@ spec:
matchLabels:
component: widget-service
consumer: consumer123

# How isolation is done at the provider side
clusterScopedIsolation: Prefixed
# informerScope is the scope of the APIServiceExport. It can be either Cluster or Namespace.
Expand All @@ -122,7 +122,7 @@ spec:
# Namespaced: The konnector has permission to watch only single namespaces.
# This is more resource intensive. And it means cluster-scoped resources cannot be exported.
informerScope: Cluster

status:
conditions:
- lastTransitionTime: "2025-11-14T12:02:29Z"
Expand Down Expand Up @@ -152,22 +152,22 @@ APIServiceBinding (consumer side)

**Purpose**: Represents a consumer's request to bind to a specific service template.

**Used by**: Service consumers (via CLI/UI)
**Scope**: Namespaced (on consumer side)
**Used by**: Service consumers (via CLI/UI)
**Scope**: Namespaced (on consumer side)
**Lifecycle**: Created during binding process, short lived until APIServiceExport is established.

### Key Features

- **Binding Initiation**: Starts the binding process between consumer and provider
- **Authentication Context**: Contains OAuth2 flow details and credentials
- **Authentication Context**: Contains OAuth2 flow details and credentials
- **Template Reference**: Points to the specific template being requested
- **Status Tracking**: Reports binding progress and any errors

### Structure

```yaml
apiVersion: kube-bind.io/v1alpha1
kind: APIServiceExportRequest
kind: APIServiceExportRequest
metadata:
name: my-widget-service-binding
namespace: default
Expand All @@ -177,7 +177,7 @@ spec:
- group: example.com
resource: widgets
versions: ["v1"]

permissionClaims:
- group: core
resource: configmaps
Expand All @@ -193,10 +193,10 @@ spec:
# resource:
# versions: []
# jsonPath:
# name:
# namespace:
# name:
# namespace:


status:
conditions:
- lastTransitionTime: "2025-11-14T12:02:25Z"
Expand All @@ -212,8 +212,8 @@ status:

**Purpose**: Represents the consumer-side binding to a provider service, containing the applied CRDs and managing the resource synchronization.

**Used by**: Automatically created by consumer konnector agents
**Scope**: Namespaced (on consumer side)
**Used by**: Automatically created by consumer konnector agents
**Scope**: Namespaced (on consumer side)
**Lifecycle**: Created when APIServiceExportRequest is processed, long-lived

### Key Features
Expand Down Expand Up @@ -280,8 +280,8 @@ status:

**Purpose**: Contains the actual CRD definitions and schema information for resources bound from a provider.

**Used by**: Created alongside APIServiceExport on provider side
**Scope**: Namespaced (on provider side)
**Used by**: Created alongside APIServiceExport on provider side
**Scope**: Namespaced (on provider side)
**Lifecycle**: Mirrors APIServiceExport lifecycle

### Key Features
Expand Down Expand Up @@ -321,7 +321,7 @@ spec:
subresources:
status: {}
# Complete OpenAPI schema definition

status:
acceptedNames:
kind: Sheriff
Expand All @@ -348,14 +348,14 @@ status:

**Purpose**: Manages namespace mapping and isolation between provider and consumer clusters.

**Used by**: Automatically managed by konnector agents
**Scope**: Namespaced (on provider side)
**Used by**: Automatically managed by konnector agents
**Scope**: Namespaced (on provider side)
**Lifecycle**: Created as needed during resource synchronization or by provider, when namespace is desired on consumer side.

### Key Features

- **Namespace Isolation**: Ensures consumer resources don't conflict
- **Mapping Logic**: Handles namespace translation between clusters
- **Mapping Logic**: Handles namespace translation between clusters
- **Resource Organization**: Groups related resources per consumer
- **Automatic Management**: Created/deleted as bindings change

Expand All @@ -373,13 +373,13 @@ APIServiceExportTemplate → defines service contract
APIServiceExportRequest → consumer requests binding
```

### 3. Provider Processing
### 3. Provider Processing
```yaml
APIServiceExport + BoundSchema → provider creates export with schema
```

### 4. Consumer Binding
```yaml
```yaml
APIServiceBinding → consumer applies CRDs and establishes sync
```

Expand Down Expand Up @@ -416,7 +416,7 @@ status:
kube-bind supports different isolation strategies:

- **Prefixed**: Consumer namespace becomes `{consumer-id}-{original-name}`
- **Namespaced**: Consumer resources go into dedicated provider namespaces
- **Namespaced**: Consumer resources go into dedicated provider namespaces
- **None**: For dedicated provider clusters where isolation isn't needed

## API Relationships and Data Flow
Expand All @@ -436,7 +436,7 @@ kube-bind supports different isolation strategies:
│ │
[Secure Connection] │
│ │
┌─────────▼───────────────────▼───────┐ Consumer Cluster
┌─────────▼───────────────────▼───────┐ Consumer Cluster
│ │
│ APIServiceExportRequest │
│ │ │
Expand All @@ -463,21 +463,21 @@ Select resources based on labels:
```yaml
permissionClaims:
- group: ""
resource: secrets
resource: secrets
selector:
labelSelector:
matchLabels:
component: my-service
environment: production
```

#### Named Resource Claims
#### Named Resource Claims
Select specific resources by name:
```yaml
permissionClaims:
- group: ""
resource: configmaps
selector:
selector:
namedResources:
- name: service-config
namespace: kube-system
Expand All @@ -494,7 +494,7 @@ permissionClaims:
selector:
references:
- resource: widgets
group: example.com
group: example.com
jsonPath:
name: spec.secretRef.name
namespace: spec.secretRef.namespace
Expand All @@ -503,11 +503,14 @@ permissionClaims:
### Claim Evaluation

Permission claims are evaluated when:

1. **Template binding occurs** - Initial claim evaluation

2. **Reference sources change** - Dynamic re-evaluation for reference claims

3. **Resource labels change** - Re-evaluation for label selector claims

## Related Documentation

- [CRD Reference](../../reference/crd/kube-bind.io/) - Complete API specifications
- [CLI Reference](../../reference/) - Command-line tool documentation
- [CRD Reference](../../reference/crd/kube-bind.io/) - Complete API specifications
- [CLI Reference](../../reference/) - Command-line tool documentation