diff --git a/content/argocd-multitenancy.md b/content/argocd-multitenancy.md index 19d40512..540250cd 100644 --- a/content/argocd-multitenancy.md +++ b/content/argocd-multitenancy.md @@ -22,7 +22,7 @@ We have set a default ArgoCD configuration in Multi Tenant Operator that fulfils - Tenant 'Owners' and 'Editors' will have full access to their ArgoCD applications - Tenants in the 'Viewers' group will have read-only access to their ArgoCD applications - Tenants can sync all namespace-scoped resources, except those that are blacklisted in the spec -- Tenants can only sync cluster-scoped resources that are whitelisted in the spec +- Tenants can only sync cluster-scoped resources that are allow-listed in the spec - Tenant 'Owners' can configure their own GitOps source repos at a tenant level - Cluster admins can prevent specific resources from syncing via ArgoCD - Cluster admins have full access to all ArgoCD applications and AppProjects diff --git a/content/faq.md b/content/faq.md index 2e2a0019..0435e5e4 100644 --- a/content/faq.md +++ b/content/faq.md @@ -6,7 +6,7 @@ ## Q. How do I deploy cluster-scoped resource via the ArgoCD integration? -**A.** Multi-Tenant Operator's ArgoCD Integration allows configuration of which cluster-scoped resources can be deployed, both globally and on a per-tenant basis. For a global whitelist that applies to all tenants, you can add both resource `group` and `kind` to the [IntegrationConfig's](./how-to-guides/integration-config.md#argocd) `spec.argocd.clusterResourceWhitelist` field. Alternatively, you can set this up on a tenant level by configuring the same details within a [Tenant's](./how-to-guides/tenant.md) `spec.argocd.appProject.clusterResourceWhitelist` field. For more details, check out the [ArgoCD integration use cases](./tutorials/argocd/enabling-multi-tenancy-argocd.md#allow-argocd-to-sync-certain-cluster-wide-resources) +**A.** Multi-Tenant Operator's ArgoCD Integration allows configuration of which cluster-scoped resources can be deployed, both globally and on a per-tenant basis. For a global allow-list that applies to all tenants, you can add both resource `group` and `kind` to the [IntegrationConfig's](./how-to-guides/integration-config.md#argocd) `spec.argocd.clusterResourceWhitelist` field. Alternatively, you can set this up on a tenant level by configuring the same details within a [Tenant's](./how-to-guides/tenant.md) `spec.argocd.appProject.clusterResourceWhitelist` field. For more details, check out the [ArgoCD integration use cases](./tutorials/argocd/enabling-multi-tenancy-argocd.md#allow-argocd-to-sync-certain-cluster-wide-resources) ## Q. InvalidSpecError: application repo \ is not permitted in project \ diff --git a/content/tutorials/argocd/enabling-multi-tenancy-argocd.md b/content/tutorials/argocd/enabling-multi-tenancy-argocd.md index 4b6aa4c4..b4e71bf2 100644 --- a/content/tutorials/argocd/enabling-multi-tenancy-argocd.md +++ b/content/tutorials/argocd/enabling-multi-tenancy-argocd.md @@ -16,7 +16,7 @@ We have set a default ArgoCD configuration in Multi Tenant Operator that fulfils - Tenant 'Owners' and 'Editors' will have full access to their ArgoCD applications - Tenants in the 'Viewers' group will have read-only access to their ArgoCD applications - Tenants can sync all namespace-scoped resources, except those that are blacklisted in the spec -- Tenants can only sync cluster-scoped resources that are whitelisted in the spec +- Tenants can only sync cluster-scoped resources that are allow-listed in the spec - Tenant 'Owners' can configure their own GitOps source repos at a tenant level - Cluster admins can prevent specific resources from syncing via ArgoCD - Cluster admins have full access to all ArgoCD applications and AppProjects @@ -171,7 +171,7 @@ spec: ## Allow ArgoCD to sync certain cluster-wide resources -Bill now wants tenants to be able to sync the `Environment` cluster scoped resource to the cluster. To do this correctly, Bill will specify the resource to whitelist in the ArgoCD portion of the Integration Config's Spec: +Bill now wants tenants to be able to sync the `Environment` cluster scoped resource to the cluster. To do this correctly, Bill will specify the resource to allow-list in the ArgoCD portion of the Integration Config's Spec: ```yaml apiVersion: tenantoperator.stakater.com/v1alpha1 @@ -189,7 +189,7 @@ spec: ... ``` -Now, if the resource is added to any tenant's project directory in GitOps, ArgoCD will sync them to the cluster. The AppProject will also have the whitelisted resources added to it: +Now, if the resource is added to any tenant's project directory in GitOps, ArgoCD will sync them to the cluster. The AppProject will also have the allow-listed resources added to it: ```yaml apiVersion: argoproj.io/v1alpha1 diff --git a/content/usecases/argocd.md b/content/usecases/argocd.md index 51121a50..7c0f2fad 100644 --- a/content/usecases/argocd.md +++ b/content/usecases/argocd.md @@ -149,7 +149,7 @@ spec: ## Allow ArgoCD to sync certain cluster-wide resources -Bill now wants tenants to be able to sync the `Environment` cluster scoped resource to the cluster. To do this correctly, Bill will specify the resource to whitelist in the ArgoCD portion of the Integration Config's Spec: +Bill now wants tenants to be able to sync the `Environment` cluster scoped resource to the cluster. To do this correctly, Bill will specify the resource to allow-list in the ArgoCD portion of the Integration Config's Spec: ```yaml apiVersion: tenantoperator.stakater.com/v1alpha1 @@ -167,7 +167,7 @@ spec: ... ``` -Now, if the resource is added to any tenant's project directory in GitOps, ArgoCD will sync them to the cluster. The AppProject will also have the whitelisted resources added to it: +Now, if the resource is added to any tenant's project directory in GitOps, ArgoCD will sync them to the cluster. The AppProject will also have the allow-listed resources added to it: ```yaml apiVersion: argoproj.io/v1alpha1 diff --git a/vocabulary b/vocabulary index 21df5efa..6df79442 160000 --- a/vocabulary +++ b/vocabulary @@ -1 +1 @@ -Subproject commit 21df5efaa8307d20c68b373d91f2204d2831f4e3 +Subproject commit 6df79442723244b60287235a6319d5d422c0b8b0