What mechanisms provide access to custom resources…

Access to Custom Resources (CR) in Kubernetes is performed through the same mechanisms as for built-in resources, but taking into account their specifics.

Main mechanisms:

Kubernetes API Server: The fundamental way of interaction. The API Server provides a RESTful API for managing all resources in the cluster, including CR.
- You can create, read, update, and delete CRs (CRUD operations) through the API Server.
- Access to the API Server is controlled by authentication, authorization, and access control (Admission Controllers).
kubectl: A command-line utility for interacting with the Kubernetes cluster.
- Uses the Kubernetes API Server to execute commands.
- Supports operations with CRs similar to standard resources, for example:
```
# Get a list of custom resources of type 'myresource'
kubectl get myresources
# Describe a specific custom resource
kubectl describe myresource my-instance-name
# Create a custom resource from a YAML file
kubectl create -f my-resource.yaml
```
- Requires the presence of a CustomResourceDefinition (CRD) in the cluster.

Clients (SDKs): Libraries for working with the Kubernetes API in various programming languages (Go, Python, Java, Ruby, etc.).

Allow programmatic interaction with CR.
Often used by controllers (Operators) to manage the lifecycle of CR.

// Example in Go with client-go
config, err := rest.InClusterConfig() // or clientcmd.BuildConfigFromFlags
if err != nil {
    // ... handle error ...
}

// Create a dynamic client to work with any resources
dynamicClient, err := dynamic.NewForConfig(config)
if err != nil {
    // ... handle error ...
}

gvr := schema.GroupVersionResource{Group: "stable.example.com", Version: "v1", Resource: "myresources"}

// Get a list of custom resources
unstructuredList, err := dynamicClient.Resource(gvr).Namespace("default").List(context.TODO(), metav1.ListOptions{})
if err != nil {
    // ... handle error ...
}

// Process the list...

Operators: An automation pattern using CRs and controllers to manage complex applications.
- Operators include logic to react to changes in CRs and perform necessary actions (e.g., creating Pods, Services, etc.).
- They use client libraries (Clients) to interact with CRs and other resources.

RBAC (Role-Based Access Control): An authorization system in Kubernetes.

Access to CRs is controlled by roles and role bindings.
Explicit permissions (verbs like get, list, create, update, delete, watch) must be granted for specific groups and resources (CRD or specific CRs).

# Example Role granting access to 'myresources'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: myresource-reader
  namespace: default
rules:
- apiGroups: ["stable.example.com"] # API group of the custom resource
  resources: ["myresources"]       # Name of the custom resource in plural form
  verbs: ["get", "list", "watch"]  # Allowed operations

Access to custom resources is indistinguishable from access to built-in resources at the API level but requires the presence of the corresponding CRD and correct RBAC rules explicitly including the API group and the name of the custom resource.

What mechanisms provide access to custom resources?