[Docs] OSSM with ZTWIM federation

[Dimss]

Removing duplicates and outdated spire docs
Adding OSSM with ZTWIM for federation setup docs

What type of PR is this?

• Enhancement / New Feature
• Bug Fix
• Refactor
• Optimization
• Test
• Documentation Update

[fjglira]

First pass, all the comment are suggestions to make the documentation easier for users

[fjglira]

This file lives upstream. Deleting I think is not the rigth approach, if we need to add something OSSM specific it should be in the ossm folder just with the ossm specific information

[fjglira]

You can leave this one here and create the federation specific in the ossm folder

[fjglira]

Suggested change

	Create two OpenShift clusters.
	Create a directory `ossm-ztwim-federation`, cd into directory `ossm-ztwim-federation`.
	To easily access both clusters,
	create two files `cluster-a.kubeconfig`
	and `cluster-b.kubeconfig`.
	Store the kubeconfig content accordingly
	* Create two OpenShift clusters.
	* Create a directory `ossm-ztwim-federation`, cd into the directory `ossm-ztwim-federation`.
	To easily access both clusters, create two files `cluster-a.kubeconfig` and `cluster-b.kubeconfig`.
	* Store the kubeconfig content accordingly

[fjglira]

Suggested change

	export OSSM_NS=istio-system
	export OSSM_CNI=istio-cni
	export OSSM_NS=istio-system
	export OSSM_CNI_NS=istio-cni

To keep the same format and be more explicit. This will need to be replaced across the etnire document where the var is used

[fjglira]

I think it is better explained step by step. But if we already have a section in the main document on How to install the operator, you can mentione and redirect people to that section install of adding a bash with a for for this in both cluster. Mention something like: for each cluster, you will need to install the Operator following the steps mentioned here for each one of the clusters

[fjglira]

Something similar here, for documentation is better to separate the steps and tell users to: create the CR on cluster A and the command annd another step create the CR on cluster B and the command

[fjglira]

Same here

[fjglira]

Suggested change

	_Note, once the `SpireAgent` deployed we must patch the agent configuration and
	_Note, once the `SpireAgent` is deployed, we must patch the agent configuration and

[fjglira]

Similar here, I think each configuration step should be a bullet point install a huge code block with comments

[fjglira]

Same here, separated bullet will make it easier to go over steps

[rausingh-rh]

Hi @Dimss ,
using trustDomainAliases will make the spire federation work with Istio but was that the main intention of trustDomainAliases field? I believe it was designed for trust domain migration.

Adding federated trust domains in trustDomainAliases would mean:

1. AuthorizationPolicy cannot distinguish between clusters meaning, any policy allowing one trust domain implicitly allows the other
2. TLS accepts any identity from any aliased trust domain meaning, inbound connections from aliased domains pass the SAN check

cc: @PillaiManish