extend documentation

On-behalf-of: @SAP christoph.mewes@sap.com

Author: xrstf

docs/content/faq.md

@@ -32,10 +32,17 @@ schema from the `APIExport`.
 
 ## Does the Sync Agent handle permission claims?
 
-Only those required for its own operation. If you configure a namespaced resource to sync, it will
-automatically add a claim for `namespaces` in kcp, plus it will add either `configmaps` or `secrets`
-if related resources are configured in a `PublishedResource`. But you cannot specify additional
-permissions claims.
+Only those required for its own operation. The syncagent will add the following permission claims
+to the APIExport it manages:
+
+* `events` (always)
+* `namespaces` (always)
+* `core.kcp.io/logicalclusters` (if `enableWorkspacePaths` is set in a `PublishedResource`)
+* any resource used as related resources (most often this means `configmaps` or `secrets`, but could
+  be any resource)
+
+The syncagent will always overwrite the entire list of permission claims, i.e. you cannot have custom
+claims in an APIExport.
 
 ## I am seeing errors in the agent logs, what's going on?
 

docs/content/publish-resources/.pages

@@ -1,5 +1,6 @@
 nav:
     - index.md
+    - related-resources.md
     - templating.md
     - api-lifecycle.md
     - technical-details.md

docs/content/publish-resources/index.md

@@ -35,7 +35,7 @@ usually originate on the service cluster and could be for example connection det
 by Crossplane, but could also originate in the user workspace and just be additional, auxiliary
 resources that need to be synced down to the service cluster.
 
-### `PublishedResource`
+## `PublishedResource`
 
 In its simplest form (which is rarely practical) a `PublishedResource` looks like this:
 
@@ -287,333 +287,7 @@ resource represents usually one, but can be multiple objects to synchronize betw
 and service cluster. While the main published resource sync is always workspace->service cluster,
 related resources can originate on either side and so either can work as the source of truth.
 
-At the moment, only `ConfigMaps` and `Secrets` are allowed related resource kinds.
-
-For each related resource, the Sync Agent needs to be told how to find the object on the origin side
-and where to create it on the destination side. There are multiple options that you can choose from.
-
-By default all related objects live in the same namespace as the primary object (their owner/parent).
-If the primary object is cluster scoped, admins must configure additional rules to specify what
-namespace the ConfigMap/Secret shall be read from and created in.
-
-Related resources are always optional. Even if references (see below) are used and their path
-expression points to a non-existing field in the primary object (e.g. `spec.secretName` is configured,
-but that field does not exist in Certificate object), this will simply be treated as "not _yet_
-existing" and not create an error.
-
-#### References
-
-A reference is a JSONPath-like expression (more precisely, it follows the [gjson syntax](https://github.com/tidwall/gjson?tab=readme-ov-file#path-syntax))
-that are evaluated on both sides of the synchronization. You configure a single path expression
-(like `spec.secretName`) and the sync agent will evaluate it in the original primary object (in kcp)
-and again in the copied primary object (on the service cluster). Since the primary object has already
-been mutated, the `spec.secretName` is already rewritten/adjusted to work on the service cluster
-(for example it was changed from `my-secret` to `jk23h4wz47329rz2r72r92-secret` on the service
-cluster side). By doing it this way, admins only have to think about mutations and rewrites once
-(when configuring the primary object in the PublishedResource) and the path will yield 2 ready to
-use values (`my-secret` and the computed value).
-
-References can either return a single scalar (strings or integers that will be auto-converted to a
-string) (like in `spec.secretName`) or a list of strings/numbers (like `spec.users.#.name`). A
-reference must return the same number of items on both the local and remote object, otherwise the
-agent will not be able to map local related names to remote related names correctly.
-
-A regular expression can be configured to be applied to each found value (i.e. if the reference returns
-a list of values, the regular expression is applied to each individual value).
-
-Here's an example on how to use references to locate the related object.
-
-{% raw %}
-```yaml
-apiVersion: syncagent.kcp.io/v1alpha1
-kind: PublishedResource
-metadata:
-  name: publish-certmanager-certs
-spec:
-  resource:
-    kind: Certificate
-    apiGroup: cert-manager.io
-    versions: [v1]
-
-  naming:
-    # this is where our CA and Issuer live in this example
-    namespace: kube-system
-    # need to adjust it to prevent collisions (normally clustername is the namespace)
-    name: "{{ .ClusterName }}-{{ .Object.metadata.namespace | sha3short }}-{{ .Object.metadata.name | sha3short }}"
-
-  related:
-    - # unique name for this related resource. The name must be unique within
-      # one PublishedResource and is the key by which consumers (end users)
-      # can identify and consume the related resource. Common names are
-      # "connection-details" or "credentials".
-      identifier: tls-secret
-
-      # "service" or "kcp"
-      origin: service
-
-      # for now, only "Secret" and "ConfigMap" are supported;
-      # there is no GVK projection for related resources
-      kind: Secret
-
-      # configure where in the parent object we can find the child object
-      object:
-        # Object can use either reference, labelSelector or template. In this
-        # example we use references.
-        reference:
-          # This path is evaluated in both the local and remote objects, to figure out
-          # the local and remote names for the related object. This saves us from having
-          # to remember mutated fields before their mutation (similar to the last-known
-          # annotation).
-          path: spec.secretName
-
-        # namespace part is optional; if not configured,
-        # Sync Agent assumes the same namespace as the owning resource
-        # namespace:
-        #   reference:
-        #     path: spec.secretName
-        #     regex:
-        #       pattern: '...'
-        #       replacement: '...'
-```
-{% endraw %}
-
-#### Templates
-
-Similar to references, [Go templates](https://pkg.go.dev/text/template) can also be used to determine
-the names of related objects on both sides of the sync. In fact, templates can be thought of as more
-powerful references since they allow for minimal logic to be embedded in them. Templates also do not
-necessarily have to select a value from the object (like a reference does), but can use any kind of
-logic to determine the names.
-
-Like references, templates can also only be used to select a single object per related resource.
-
-A template gets the following data injected into it:
-
-```go
-type localObjectNamingContext struct {
-	// Side is set to either one of the possible origin values to indicate for
-	// which cluster the template is currently being evaluated for.
-	Side syncagentv1alpha1.RelatedResourceOrigin
-	// Object is the primary object belonging to the related object. Since related
-	// object templates are evaluated twice (once for the origin side and once
-	// for the destination side), object is the primary object on the side the
-	// template is evaluated for.
-	Object map[string]any
-	// ClusterName is the internal cluster identifier (e.g. "34hg2j4gh24jdfgf")
-	// of the kcp workspace that the synchronization is currently processing. This
-	// value is set for both evaluations, regardless of side.
-	ClusterName logicalcluster.Name
-	// ClusterPath is the workspace path (e.g. "root:customer:projectx"). This
-	// value is set for both evaluations, regardless of side.
-	ClusterPath logicalcluster.Path
-}
-```
-
-In the simplest form, a template can replace a reference:
-
-* reference: `.spec.secretName`
-* Go template: {% raw %}`{{ .Object.spec.secretName }}`{% endraw %}
-
-Just like with references, the configured template is evaluated twice, once for each side of the
-synchronization. You can use the `Side` variable to allow for fully customized names on each side:
-
-{% raw %}
-```yaml
-spec:
-  ...
-  related:
-    - identifier: tls-secret
-      # ..omitting other fields..
-      object:
-        template:
-          template: `{{ if eq .Side "kcp" }}name-in-kcp{{ else }}name-on-service-cluster{{ end }}`
-```
-{% endraw %}
-
-See [Templating](templating.md) for more information on how to use templates in PublishedResources.
-
-#### Label Selectors
-
-In some cases, the primary object does not have a link to its child/children objects. In these cases,
-a label selector can be used. This allows to configure the labels that any related object must have
-to be included.
-
-Notably, this allows for _multiple_ objects that are synced for a single configured related resource.
-The sync agent will not prevent misconfigurations, so great care must be taken when configuring
-selectors to not accidentally include too many objects.
-
-Additionally, it is assumed that
-
-* Primary objects synced from kcp to a service cluster will be renamed, to prevent naming collisions.
-* The renamed objects on the service cluster might contain private, sensitive information that should
-  not be leaked into kcp workspaces.
-* When there is no explicit name being requested (like by setting `spec.secretName`), it can be
-  assumed that the operator on the service cluster that is actually processing the primary object
-  will use the primary object's name (at least in parts) to construct the names of related objects,
-  for example a Certificate `yaddasupersecretyadda` might automatically get a Secret created named
-  `yaddasupersecretyadda-secret`.
-
-Since the name of the related object must not leak into a kcp workspace, admins who configure a
-label selector also always have to provide a naming scheme for the copies of the related objects on
-the destination side.
-
-Namespaces work the same as with references, i.e. by default the same namespace as the primary object
-is assumed. However you can actually also use label selectors to find the origin _namespaces_
-dynamically. So you can configure two label selectors, and then agent will first use the namespace
-selector to find all applicable namespaces, and then use the other label selector _in each of the
-applicable namespaces_ to finally locate the related objects. How useful this is depends a lot on
-how peculiar the underlying operators on the service clusters are.
-
-Here is an example on how to use label selectors:
-
-{% raw %}
-```yaml
-apiVersion: syncagent.kcp.io/v1alpha1
-kind: PublishedResource
-metadata:
-  name: publish-certmanager-certs
-spec:
-  resource:
-    kind: Certificate
-    apiGroup: cert-manager.io
-    versions: [v1]
-
-  naming:
-    namespace: kube-system
-    name: "{{ .ClusterName }}-{{ .Object.metadata.namespace | sha3short }}-{{ .Object.metadata.name | sha3short }}"
-
-  related:
-    - identifier: tls-secrets
-
-      # "service" or "kcp"
-      origin: service
-
-      # for now, only "Secret" and "ConfigMap" are supported;
-      # there is no GVK projection for related resources
-      kind: Secret
-
-      # configure where in the parent object we can find the child object
-      object:
-        # A selector is a standard Kubernetes label selector, supporting
-        # matchLabels and matchExpressions.
-        selector:
-          matchLabels:
-            my-key: my-value
-            another: pair
-            # Within matchLabels, keys and values are treated as Go templates.
-            # In this example, since the Secret originates on the service cluster
-            # (see "origin" above), we use LocalObject to determine the value
-            # for the selector. In case the object was heavily mutated during the
-            # sync, this will give access to the mutated values on the service
-            # cluster side.
-            '{{ shasum "test" }}': '{{ .LocalObject.spec.username }}'
-
-          # You also need to provide rules on how objects found by this selector
-          # should be named on the destination side of the sync. You can choose
-          # to define a rewrite rule that keeps the original name from the origin
-          # side, but this may leak undesirable internals to the users.
-          # Rewrites are either using regular expressions or templated strings,
-          # never both.
-          # The rewrite config is applied to each individual found object.
-          rewrite:
-            regex:
-              pattern: "foo-(.+)"
-              replacement: "bar-\\1"
-
-            # or
-            template:
-              template: "{{ .Value }}-foo"
-
-        # Like with references, the namespace can (or must) be configured explicitly.
-        # You do not need to also use label selectors here, you can mix and match
-        # freely.
-        # namespace:
-        #   reference:
-        #     path: metadata.namespace
-        #     regex:
-        #       pattern: '...'
-        #       replacement: '...'
-```
-{% endraw %}
-
-There are two possible usages of Go templates when using label selectors. See [Templating](templating.md)
-for more information on how to use templates in PublishedResources in general.
-
-##### Selector Templates
-
-Each template rendered as part of a `matchLabels` selector gets the following data injected:
-
-```go
-type relatedObjectLabelContext struct {
-	// LocalObject is the primary object copy on the local side of the sync
-	// (i.e. on the service cluster).
-	LocalObject map[string]any
-	// RemoteObject is the primary object original, in kcp.
-	RemoteObject map[string]any
-	// ClusterName is the internal cluster identifier (e.g. "34hg2j4gh24jdfgf")
-	// of the kcp workspace that the synchronization is currently processing
-	// (where the remote object exists).
-	ClusterName logicalcluster.Name
-	// ClusterPath is the workspace path (e.g. "root:customer:projectx").
-	ClusterPath logicalcluster.Path
-}
-```
-
-Note that in contrast to the `template` way of selecting objects, the templates here in the label
-selector are only evaluated once, on the origin side of the sync. The names of the destination side
-are determined using the rewrite mechanism (which might also be a Go template, see next section).
-
-##### Rewrite Rules
-
-Each found related object on the origin side needs to have its own name on the destination side. To
-map from the origin to the destination side, regular expressions (see example snippet) or Go
-templates can be used.
-
-If a template is configured, it is evaluated once for every found related object. The template gets
-the following data injected into it:
-
-```go
-type relatedObjectLabelRewriteContext struct {
-	// Value is either the a found namespace name (when a label selector was
-	// used to select the source namespaces for related objects) or the name of
-	// a found object (when a label selector was used to find objects). In the
-	// former case, the template should return the new namespace to use on the
-	// destination side, in the latter case it should return the new object name
-	// to use on the destination side.
-	Value string
-	// When a rewrite is used to rewrite object names, RelatedObject is the
-	// original related object (found on the origin side). This enables you to
-	// ignore the given Value entirely and just select anything from the object
-	// itself.
-	// RelatedObject is nil when the rewrite is performed for a namespace.
-	RelatedObject map[string]any
-	// LocalObject is the primary object copy on the local side of the sync
-	// (i.e. on the service cluster).
-	LocalObject map[string]any
-	// RemoteObject is the primary object original, in kcp.
-	RemoteObject map[string]any
-	// ClusterName is the internal cluster identifier (e.g. "34hg2j4gh24jdfgf")
-	// of the kcp workspace that the synchronization is currently processing
-	// (where the remote object exists).
-	ClusterName logicalcluster.Name
-	// ClusterPath is the workspace path (e.g. "root:customer:projectx").
-	ClusterPath logicalcluster.Path
-}
-```
-
-Regarding `Value`: The agent allows to individually configure rules for finding object _names_ and
-object _namespaces_. Often the namespace is not configured because the related objects live in the
-same namespace as their owning, primary object.
-
-When a label selector is configured to find namespaces, the rewrite template will be evaluated once
-for each found namespace. In this case the `.Value` is the name of the found namespace. Remember, the
-template's job is to map the found namespace to the new namespace on the destination side of the sync.
-
-Once the namespaces have been determined, the agent will look for matching objects in each namespace
-individually. For each namespace it will again follow the configured source, may it be a selector,
-template or reference. If again a label selector is used, it will be applied in each namespace and
-the configured rewrite rule will be evaluated once per found object. In this case, `.Value` is the
-name of found object.
+More information is available in the [related resources guide](./related-resources.md).
 
 ## Examples
 
@@ -650,9 +324,11 @@ spec:
     name: "{{ .ClusterName }}-{{ .Object.metadata.namespace | sha3short }}-{{ .Object.metadata.name | sha3short }}"
 
   related:
-    - origin: service # service or kcp
-      kind: Secret    # for now, only "Secret" and "ConfigMap" are supported;
-                      # there is no GVK projection for related resources
+    - identifier: tls-secrets
+      origin: service # service or kcp
+      group: ""
+      version: v1
+      resource: secrets
 
       # configure where in the parent object we can find
       # the name/namespace of the related resource (the child)