From 9064a5898090e0041f4b9a8afa3c67128a914dfc Mon Sep 17 00:00:00 2001 From: Angel Date: Tue, 7 Jan 2025 15:21:42 -0500 Subject: [PATCH 01/10] workspaces --- app/_gateway_entities/workspace.md | 130 +++++++++++++++++- app/_landing_pages/gateway/multi-tenancy.yaml | 18 +++ app/deck/managed-entities.md | 30 ++++ .../permissions/roles-and-permissions.md | 13 ++ 4 files changed, 187 insertions(+), 4 deletions(-) create mode 100644 app/_landing_pages/gateway/multi-tenancy.yaml create mode 100644 app/deck/managed-entities.md create mode 100644 app/gateway/permissions/roles-and-permissions.md diff --git a/app/_gateway_entities/workspace.md b/app/_gateway_entities/workspace.md index 8dd64fb7..68333564 100644 --- a/app/_gateway_entities/workspace.md +++ b/app/_gateway_entities/workspace.md @@ -4,7 +4,7 @@ content_type: reference entities: - workspace -description: Workspaces provide a way to segment {{site.base_gateway}} entities. Entities in a workspace are isolated from those in other workspaces. +description: Workspaces provide a way to segment {{site.base_gateway}} entities. Entities in a Workspace are isolated from those in other Workspaces. tools: - admin-api @@ -16,14 +16,136 @@ tier: enterprise schema: api: gateway/admin-ee path: /schemas/Workspace + +faqs: + - q: Do I have to enable Workspaces? + a: | + {{site.base_gateway}} ships with Workspaces, the default Workspace is named `default` and contains any global {{site.base_gateway}} configuration. + - q: Are there entities that can't exist in a Workspace? + a: | + Yes, some entities are global meaning they don't exist in any individual Workspace. For example `ca_certificates`. + - q: Can I use Workspaces in Konnect? + a: | + Konnect offers access to the more power Consumer Groups [/gateway/entities/consumer-group/] + + - q: Can a Workspace share a name with another Workspace? + a: | + Individual Workspaces can be managed using [decK](/deck/). However, decK can't manage multiple Workspaces at the same time, or delete Workspaces. + --- -TODO -## What is a workspace? +## What is a Workspace? + +Workspaces are a way of namespacing {{site.base_gateway}} entities so they can be managed indepdently. Workspaces maintain a unified routing table on the data plane to support client traffic segmentation. + +The data plane routes client traffic based on the configuration applied across all Workspaces. Configuring entities related to routing such as Services and Routes alter the client traffic routing behavior of the data plane but {{site.base_gateway}} will always attempt to ensure that routing rules don't contain conflicts. + +{% mermaid %} +flowchart LR + subgraph Workspace1 [Workspace-1] + A(Team A's Service) + B(Route) + end -This page is a stub + subgraph Workspace2 [Workspace-2] + C(Team B's - Service) + D(Route) + + end + + subgraph Workspace3 [Workspace-3] + E(Team C's - Service) + F(Route) + end + subgraph Gatewayorg [Gateway Organization] + Workspace1 + Workspace2 + Workspace3 + end + +{% endmermaid %} ## Schema {% entity_schema %} + + +### Conflict detection algorithm + +Routing rules are configured at the data plane level. To ensure that traffic can be routed to the appropriate Workspace, {{site.base_gateway}} uses a conflict detection algorithm. The algorithm can be explained like this: + +When a Service or Route is **created** or **modified**, the {{site.base_gateway}} Router performs the following sequence to check for duplicate or matchine rules: + +1. If no matches found: The operation proceeds. +2. If a match is found in the same Workspace: The operation proceeds +3. If a match is found in a different Workspace: + * If the matching Service or Route has no host value: issue a `409 Conflict` error + * If the host is a wildcard: + * if it matches issue a `409 Conflict` error + * If it doesn't match, the operation proceeds. + * If the host is an absolute value: Issue a `409 Conflict` error. + +## Roles, groups, and permissions + +Workspaces allow users to control {{site.base_gateway}} entities in isolation. Individual permissions for Workspaces are configured using RBAC. Roles are sets of permissions that can be assigned to admins and users and can be specific to a Workspace. There are two types of Admin roles in {{site.base_gateway}}: **Super Admin** and **Admin**. + +A super admin within the contexts of Workspaces can perform the following actions: +* Create new Workspaces +* Assign and revoke roles to admins +* Manage all Workspaces across the organization + +An admin within the context of Workspaces can only manage entities within the specified Workspace. + +For more information see [Roles and permissions](/gateway/roles-and-permissions) + + +## Multi-tenant Control Plane and Data Plane + +Multi-tenancy is supported with Workspaces. Workspaces provide an isolation of {{site.base_gateway}} configuration objects while maintaining a unified routing table on the data plane to support client traffic. You can create Workspaces for teams, business units, environments, projects or other aspects of your system. + +When pairing Workspaces with RBAC, {{site.base_gateway}} administrators can effectively create tenants within the control plane. The {{site.base_gateway}} administrator creates Workspaces and assigns administrators to them. The Workspace administrators have segregated and secure access to only their portion of the {{site.base_gateway}} configuration in Kong Manager, the Admin API, and the declarative configuration tool decK. + + +How you design your Workspaces is largely influenced by your specific requirements and the layout of your organization. You may choose to create Workspaces for teams, business units, environments, projects, or some other aspect of your system. + + +For more information, view [Multi-tenant architecture ](/gateway/multi-tenancy) + +### Manage multiple Workspaces with decK + +The following decK flags must be used when interfacing with Workspaces using decK. + +```sh +deck gateway dump --all-workspaces +``` +This will dump your configuration into individual yaml files with the specific Workspace name including `default`. + +You can set a Workspace specifically within a decK file like this: + +``` +_format_version: "3.0" +_workspace: default +services: +- name: example_service +``` +### Deploying Workspace-specific config + +Configurations deployed with decK must be deployed on a per-Workspace basis, indvidually. This is achieved using the `--workspace` flag: + +`deck gateway sync default.yaml --workspace default` + + +### Delete Workspace configuration + +decK can't delete Workspaces. However, using `deck gateway reset` in combination with the `--workspace` or `--all-workspaces` flags forces decK to delete the entire configuration inside the Workspace, but not the Workspace itself. + + +## Configure a Workspace + +{% entity_example %} +type: workspace +data: + name: "my-workspace" +{% endentity_example %} + diff --git a/app/_landing_pages/gateway/multi-tenancy.yaml b/app/_landing_pages/gateway/multi-tenancy.yaml new file mode 100644 index 00000000..bcbde469 --- /dev/null +++ b/app/_landing_pages/gateway/multi-tenancy.yaml @@ -0,0 +1,18 @@ +metadata: + title: Multi-tenancy and Kong + content_type: landing_page + description: "This page explains how to build multi-tenant architecture" + +rows: + - header: + type: h1 + text: "@TODO" + columns: + - blocks: + - type: structured_text + config: + blocks: + - type: text + text: | + Insomnia plugins can be used to extend the functionality of Insomnia. + They are commonly used for advanced features, such as custom authentication mechanisms and complex workflows. They can also be used to customize the Insomnia theme. diff --git a/app/deck/managed-entities.md b/app/deck/managed-entities.md new file mode 100644 index 00000000..b360f0d7 --- /dev/null +++ b/app/deck/managed-entities.md @@ -0,0 +1,30 @@ +--- +title: Entities Managed by decK + +description: "decK manages entity configuration for{{site.base_gateway}}, including all core proxy entities." + +content_type: reference +layout: reference + +works_on: + - on-prem + - konnect + +products: + - api-ops + +tools: + - deck + +related_resources: + - text: Customize decK object defaults + url: /how-to/custom-deck-object-defaults + +breadcrumbs: + - /deck/ +--- + +@todo +Everything on this list so it can be referenced in one place when talking about what decK can manage. +https://docs.konghq.com/deck/latest/reference/entities/ + diff --git a/app/gateway/permissions/roles-and-permissions.md b/app/gateway/permissions/roles-and-permissions.md new file mode 100644 index 00000000..dcf508e8 --- /dev/null +++ b/app/gateway/permissions/roles-and-permissions.md @@ -0,0 +1,13 @@ +--- +title: Roles and Permissions + +description: This explains Roles and permissions +content_type: reference +layout: reference +tier: enterprise +products: + - gateway + +--- + +@todo Contains all role and permissions info for Admins and Super Admins \ No newline at end of file From 9195d8a273141f259b157ef734ab2b7b8b8fa090 Mon Sep 17 00:00:00 2001 From: Angel Date: Tue, 7 Jan 2025 15:25:37 -0500 Subject: [PATCH 02/10] vale --- app/_gateway_entities/workspace.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/app/_gateway_entities/workspace.md b/app/_gateway_entities/workspace.md index 68333564..ead5b136 100644 --- a/app/_gateway_entities/workspace.md +++ b/app/_gateway_entities/workspace.md @@ -37,7 +37,7 @@ faqs: ## What is a Workspace? -Workspaces are a way of namespacing {{site.base_gateway}} entities so they can be managed indepdently. Workspaces maintain a unified routing table on the data plane to support client traffic segmentation. +Workspaces are a way of namespacing {{site.base_gateway}} entities so they can be managed independently. Workspaces maintain a unified routing table on the data plane to support client traffic segmentation. The data plane routes client traffic based on the configuration applied across all Workspaces. Configuring entities related to routing such as Services and Routes alter the client traffic routing behavior of the data plane but {{site.base_gateway}} will always attempt to ensure that routing rules don't contain conflicts. @@ -75,7 +75,7 @@ flowchart LR Routing rules are configured at the data plane level. To ensure that traffic can be routed to the appropriate Workspace, {{site.base_gateway}} uses a conflict detection algorithm. The algorithm can be explained like this: -When a Service or Route is **created** or **modified**, the {{site.base_gateway}} Router performs the following sequence to check for duplicate or matchine rules: +When a Service or Route is **created** or **modified**, the {{site.base_gateway}} Router performs the following sequence to check for duplicate or matching rules: 1. If no matches found: The operation proceeds. 2. If a match is found in the same Workspace: The operation proceeds @@ -131,7 +131,7 @@ services: ``` ### Deploying Workspace-specific config -Configurations deployed with decK must be deployed on a per-Workspace basis, indvidually. This is achieved using the `--workspace` flag: +Configurations deployed with decK must be deployed on a per-Workspace basis, individually. This is achieved using the `--workspace` flag: `deck gateway sync default.yaml --workspace default` From 2f79f494dc4a39d44597d7f7515acb39fae5058f Mon Sep 17 00:00:00 2001 From: Angel Date: Thu, 9 Jan 2025 13:22:16 -0500 Subject: [PATCH 03/10] Apply suggestions from code review Co-authored-by: Diana <75819066+cloudjumpercat@users.noreply.github.com> --- app/_gateway_entities/workspace.md | 60 +++++++++++++++--------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/app/_gateway_entities/workspace.md b/app/_gateway_entities/workspace.md index ead5b136..47ca7e7a 100644 --- a/app/_gateway_entities/workspace.md +++ b/app/_gateway_entities/workspace.md @@ -41,6 +41,12 @@ Workspaces are a way of namespacing {{site.base_gateway}} entities so they can b The data plane routes client traffic based on the configuration applied across all Workspaces. Configuring entities related to routing such as Services and Routes alter the client traffic routing behavior of the data plane but {{site.base_gateway}} will always attempt to ensure that routing rules don't contain conflicts. +Workspaces support multi-tenancy in that they isolate {{site.base_gateway}} configuration objects and when paired with RBAC, {{site.base_gateway}} administrators can effectively create tenants within the control plane. The Workspace administrators have segregated and secure access to only their portion of the {{site.base_gateway}} configuration in Kong Manager, the Admin API, and the declarative configuration tool decK. + +How you design your Workspaces is largely influenced by your specific requirements and the layout of your organization. You may choose to create Workspaces for teams, business units, environments, projects, or some other aspect of your system. + + +For more information, see [Multi-tenant architecture ](/gateway/multi-tenancy). {% mermaid %} flowchart LR subgraph Workspace1 [Workspace-1] @@ -66,52 +72,42 @@ flowchart LR {% endmermaid %} -## Schema -{% entity_schema %} +### How does {{site.base_gateway}} resolve entity conflicts between Workspaces? -### Conflict detection algorithm +Routing rules are configured at the data plane level. The data plane routes client traffic based on the configuration applied across all Workspaces. Configuring entities related to routing, such as [Gateway Services](/gateway/entities/service/) and [Routes](/gateway/entities/route/), alter the client traffic routing behavior of the data plane, but {{site.base_gateway}} will always attempt to ensure that routing rules don't contain conflicts. -Routing rules are configured at the data plane level. To ensure that traffic can be routed to the appropriate Workspace, {{site.base_gateway}} uses a conflict detection algorithm. The algorithm can be explained like this: +To route traffic to the appropriate Workspace, {{site.base_gateway}} uses a conflict detection algorithm. -When a Service or Route is **created** or **modified**, the {{site.base_gateway}} Router performs the following sequence to check for duplicate or matching rules: +When a Service or Route is **created** or **modified**, the {{site.base_gateway}} Router does the following: 1. If no matches found: The operation proceeds. -2. If a match is found in the same Workspace: The operation proceeds -3. If a match is found in a different Workspace: +2. If a Service or Route match is found in the Workspace that matches the one listed in the request: The operation proceeds +3. If a Service or Route match is found in a different Workspace: * If the matching Service or Route has no host value: issue a `409 Conflict` error * If the host is a wildcard: - * if it matches issue a `409 Conflict` error + * If it matches, issue a `409 Conflict` error * If it doesn't match, the operation proceeds. * If the host is an absolute value: Issue a `409 Conflict` error. ## Roles, groups, and permissions -Workspaces allow users to control {{site.base_gateway}} entities in isolation. Individual permissions for Workspaces are configured using RBAC. Roles are sets of permissions that can be assigned to admins and users and can be specific to a Workspace. There are two types of Admin roles in {{site.base_gateway}}: **Super Admin** and **Admin**. - -A super admin within the contexts of Workspaces can perform the following actions: -* Create new Workspaces -* Assign and revoke roles to admins -* Manage all Workspaces across the organization - -An admin within the context of Workspaces can only manage entities within the specified Workspace. - -For more information see [Roles and permissions](/gateway/roles-and-permissions) +Because Workspaces allow users to control {{site.base_gateway}} entities in isolation, users must have the correct permissions to configure a particular Workspace. Users will require either a Super Admin or Admin role to configure Workspaces. +The following table details which Workspace permissions each Admin role has: -## Multi-tenant Control Plane and Data Plane +| Permission | Super Admin | Admin | +|-----------|---------------|-------| +| Manage entities within the specified Workspace | ✅ | ✅ | +| Create new Workspaces | ✅ | ❌ | +| Assign and revoke roles to admins | ✅ | ❌ | +| Manage all Workspaces across the organization | ✅ | ❌ | -Multi-tenancy is supported with Workspaces. Workspaces provide an isolation of {{site.base_gateway}} configuration objects while maintaining a unified routing table on the data plane to support client traffic. You can create Workspaces for teams, business units, environments, projects or other aspects of your system. +For more information, see [Roles and permissions](/gateway/roles-and-permissions). -When pairing Workspaces with RBAC, {{site.base_gateway}} administrators can effectively create tenants within the control plane. The {{site.base_gateway}} administrator creates Workspaces and assigns administrators to them. The Workspace administrators have segregated and secure access to only their portion of the {{site.base_gateway}} configuration in Kong Manager, the Admin API, and the declarative configuration tool decK. -How you design your Workspaces is largely influenced by your specific requirements and the layout of your organization. You may choose to create Workspaces for teams, business units, environments, projects, or some other aspect of your system. - - -For more information, view [Multi-tenant architecture ](/gateway/multi-tenancy) - ### Manage multiple Workspaces with decK The following decK flags must be used when interfacing with Workspaces using decK. @@ -129,19 +125,23 @@ _workspace: default services: - name: example_service ``` -### Deploying Workspace-specific config +### Deploy Workspace-specific config -Configurations deployed with decK must be deployed on a per-Workspace basis, individually. This is achieved using the `--workspace` flag: +decK configurations must be deployed on a per-Workspace basis, individually. This is achieved using the `--workspace` flag: `deck gateway sync default.yaml --workspace default` -### Delete Workspace configuration +### Delete a Workspace configuration decK can't delete Workspaces. However, using `deck gateway reset` in combination with the `--workspace` or `--all-workspaces` flags forces decK to delete the entire configuration inside the Workspace, but not the Workspace itself. -## Configure a Workspace +## Schema + +{% entity_schema %} + +## Set up a Workspace {% entity_example %} type: workspace From 6e798c1dd14a97e08edb3f0dcb0c9d1687ba8aec Mon Sep 17 00:00:00 2001 From: Angel Date: Thu, 9 Jan 2025 13:23:43 -0500 Subject: [PATCH 04/10] Apply suggestions from code review Co-authored-by: Diana <75819066+cloudjumpercat@users.noreply.github.com> --- app/_gateway_entities/workspace.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/app/_gateway_entities/workspace.md b/app/_gateway_entities/workspace.md index 47ca7e7a..88b4abbb 100644 --- a/app/_gateway_entities/workspace.md +++ b/app/_gateway_entities/workspace.md @@ -20,17 +20,17 @@ schema: faqs: - q: Do I have to enable Workspaces? a: | - {{site.base_gateway}} ships with Workspaces, the default Workspace is named `default` and contains any global {{site.base_gateway}} configuration. + No, {{site.base_gateway}} Enterprise ships with the `default` Workspace, which contains any global {{site.base_gateway}} configuration. - q: Are there entities that can't exist in a Workspace? a: | Yes, some entities are global meaning they don't exist in any individual Workspace. For example `ca_certificates`. - q: Can I use Workspaces in Konnect? a: | - Konnect offers access to the more power Consumer Groups [/gateway/entities/consumer-group/] + No. Instead, {{site.konnect_short_name}} offers the more powerful Consumer Groups [/gateway/entities/consumer-group/] to organize and categorize of Consumers (users or applications) within an API ecosystem - q: Can a Workspace share a name with another Workspace? a: | - Individual Workspaces can be managed using [decK](/deck/). However, decK can't manage multiple Workspaces at the same time, or delete Workspaces. + Yes --- @@ -39,7 +39,7 @@ faqs: Workspaces are a way of namespacing {{site.base_gateway}} entities so they can be managed independently. Workspaces maintain a unified routing table on the data plane to support client traffic segmentation. -The data plane routes client traffic based on the configuration applied across all Workspaces. Configuring entities related to routing such as Services and Routes alter the client traffic routing behavior of the data plane but {{site.base_gateway}} will always attempt to ensure that routing rules don't contain conflicts. +Workspaces can't share entities, like Services, between them. Only users with the correct Workspace permissions can manage entities in a particular Workspace. Workspaces support multi-tenancy in that they isolate {{site.base_gateway}} configuration objects and when paired with RBAC, {{site.base_gateway}} administrators can effectively create tenants within the control plane. The Workspace administrators have segregated and secure access to only their portion of the {{site.base_gateway}} configuration in Kong Manager, the Admin API, and the declarative configuration tool decK. From 4bd8bf199f07d4e738a13a3b7b3e8ef0d0845edd Mon Sep 17 00:00:00 2001 From: Angel Date: Thu, 9 Jan 2025 14:02:54 -0500 Subject: [PATCH 05/10] fix broken link --- app/gateway/{permissions => }/roles-and-permissions.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename app/gateway/{permissions => }/roles-and-permissions.md (100%) diff --git a/app/gateway/permissions/roles-and-permissions.md b/app/gateway/roles-and-permissions.md similarity index 100% rename from app/gateway/permissions/roles-and-permissions.md rename to app/gateway/roles-and-permissions.md From 43249e16eb09f3e828bba562d93bed9828e52ccc Mon Sep 17 00:00:00 2001 From: Angel Date: Thu, 9 Jan 2025 15:56:04 -0500 Subject: [PATCH 06/10] Diana comments and feedback + UI instructions --- app/_gateway_entities/workspace.md | 29 +++++++------------ .../components/entity_example/format/ui.md | 8 +++++ 2 files changed, 19 insertions(+), 18 deletions(-) diff --git a/app/_gateway_entities/workspace.md b/app/_gateway_entities/workspace.md index 88b4abbb..a90019c6 100644 --- a/app/_gateway_entities/workspace.md +++ b/app/_gateway_entities/workspace.md @@ -37,20 +37,13 @@ faqs: ## What is a Workspace? -Workspaces are a way of namespacing {{site.base_gateway}} entities so they can be managed independently. Workspaces maintain a unified routing table on the data plane to support client traffic segmentation. +Workspaces are a way of namespacing {{site.base_gateway}} entities so they can be managed independently. Workspaces work in combination with RBAC to create isolated environments for teams to operate independently of each other. Workspaces can't share entities, like Services, between them, and only Workspace Admins with the correct permissions, in the Workspace, can manage them. Workspaces support [multi-tenancy](/gateway/multi-tenancy) by isolating {{site.base_gateway}} configuration objects and when paired with RBAC, {{site.base_gateway}} administrators can effectively create tenants within the control plane. The Workspace administrators have segregated and secure access to only their portion of the {{site.base_gateway}} configuration in Kong Manager, the Admin API, and the declarative configuration tool decK. -Workspaces can't share entities, like Services, between them. Only users with the correct Workspace permissions can manage entities in a particular Workspace. -Workspaces support multi-tenancy in that they isolate {{site.base_gateway}} configuration objects and when paired with RBAC, {{site.base_gateway}} administrators can effectively create tenants within the control plane. The Workspace administrators have segregated and secure access to only their portion of the {{site.base_gateway}} configuration in Kong Manager, the Admin API, and the declarative configuration tool decK. - -How you design your Workspaces is largely influenced by your specific requirements and the layout of your organization. You may choose to create Workspaces for teams, business units, environments, projects, or some other aspect of your system. - - -For more information, see [Multi-tenant architecture ](/gateway/multi-tenancy). {% mermaid %} flowchart LR subgraph Workspace1 [Workspace-1] - A(Team A's Service) + A(Team A's - Service) B(Route) end @@ -80,17 +73,18 @@ Routing rules are configured at the data plane level. The data plane routes clie To route traffic to the appropriate Workspace, {{site.base_gateway}} uses a conflict detection algorithm. -When a Service or Route is **created** or **modified**, the {{site.base_gateway}} Router does the following: +When a Service or Route is **created** or **modified**, the {{site.base_gateway}} Router checks for the existence of that object before allowing the operation to proceed in this order: -1. If no matches found: The operation proceeds. -2. If a Service or Route match is found in the Workspace that matches the one listed in the request: The operation proceeds -3. If a Service or Route match is found in a different Workspace: - * If the matching Service or Route has no host value: issue a `409 Conflict` error - * If the host is a wildcard: - * If it matches, issue a `409 Conflict` error - * If it doesn't match, the operation proceeds. +* If the Service or Route created is totally unique and does not match an existing entity, the new entity is created. +* If an existing Service or Route object that matches the one being created is found, a `409 Conflict` error is returned. +* If an equivalent Service or a Route is found in a different Workspace, the new entity is created. +* If an equivalent Service or Route is found in a different Workspace, and the host is a wildcard: + * If the host field matches in both workspaces, a `409 Conflict` error is returned. + * If the host field does not match, the new entity can be created. * If the host is an absolute value: Issue a `409 Conflict` error. + + ## Roles, groups, and permissions Because Workspaces allow users to control {{site.base_gateway}} entities in isolation, users must have the correct permissions to configure a particular Workspace. Users will require either a Super Admin or Admin role to configure Workspaces. @@ -107,7 +101,6 @@ The following table details which Workspace permissions each Admin role has: For more information, see [Roles and permissions](/gateway/roles-and-permissions). - ### Manage multiple Workspaces with decK The following decK flags must be used when interfacing with Workspaces using decK. diff --git a/app/_includes/components/entity_example/format/ui.md b/app/_includes/components/entity_example/format/ui.md index b3788ecb..26513718 100644 --- a/app/_includes/components/entity_example/format/ui.md +++ b/app/_includes/components/entity_example/format/ui.md @@ -64,3 +64,11 @@ The following creates a new Upstream with basic configuration: {% else %} {% endcase %} {% endif %} + +{% when 'workspace' %} +The following creates a new Workspace: + +1. From the Kong Manager Dashboard select **New Workspace** +2. Add a name, then select **Create New Workspace** + +This will create a new Workspace, and from here you can start managing entities from Kong Manager. \ No newline at end of file From 7bd1ddbf45661d8edecbaa72bdab089e37dce5f4 Mon Sep 17 00:00:00 2001 From: Angel Date: Thu, 9 Jan 2025 16:51:04 -0500 Subject: [PATCH 07/10] fix ui --- app/_includes/components/entity_example/format/ui.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/app/_includes/components/entity_example/format/ui.md b/app/_includes/components/entity_example/format/ui.md index 26513718..bd62ff67 100644 --- a/app/_includes/components/entity_example/format/ui.md +++ b/app/_includes/components/entity_example/format/ui.md @@ -60,15 +60,14 @@ The following creates a new Upstream with basic configuration: 2. Click **New Upstream**. 3. Enter a unique name for the Upstream. For example: `{{ include.presenter.data['name'] }}`. 4. Click **Save**. -{% when workspace %} -{% else %} -{% endcase %} -{% endif %} - {% when 'workspace' %} The following creates a new Workspace: 1. From the Kong Manager Dashboard select **New Workspace** 2. Add a name, then select **Create New Workspace** -This will create a new Workspace, and from here you can start managing entities from Kong Manager. \ No newline at end of file +This will create a new Workspace, and from here you can start managing entities from Kong Manager. +{% else %} +{% endcase %} +{% endif %} + From 6c85a4fefb7152ce835ffe9214ddb36199b24099 Mon Sep 17 00:00:00 2001 From: Angel Date: Fri, 10 Jan 2025 14:12:50 -0500 Subject: [PATCH 08/10] convert table --- app/_gateway_entities/workspace.md | 29 +++++++++++++++++++++++------ 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/app/_gateway_entities/workspace.md b/app/_gateway_entities/workspace.md index a90019c6..2f21fb3c 100644 --- a/app/_gateway_entities/workspace.md +++ b/app/_gateway_entities/workspace.md @@ -91,12 +91,29 @@ Because Workspaces allow users to control {{site.base_gateway}} entities in isol The following table details which Workspace permissions each Admin role has: -| Permission | Super Admin | Admin | -|-----------|---------------|-------| -| Manage entities within the specified Workspace | ✅ | ✅ | -| Create new Workspaces | ✅ | ❌ | -| Assign and revoke roles to admins | ✅ | ❌ | -| Manage all Workspaces across the organization | ✅ | ❌ | +{% feature_table %} +columns: + - title: Super Admin + key: super_admin + - title: Admin + key: admin + +features: + + - title: Manage entities within the specified Workspace + super_admin: true + admin: true + - title: Create new Workspaces + super_admin: true + admin: false + - title: Assign and revoke roles to admins + super_admin: true + admin: false + - title: Manage all Workspaces across the organization + super_admin: true + admin: false + +{% endfeature_table %} For more information, see [Roles and permissions](/gateway/roles-and-permissions). From 1f92795b78c85d9ee58a42ee87a73d6f9195a15c Mon Sep 17 00:00:00 2001 From: Angel Date: Fri, 10 Jan 2025 14:23:53 -0500 Subject: [PATCH 09/10] Update workspace.md --- app/_gateway_entities/workspace.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/app/_gateway_entities/workspace.md b/app/_gateway_entities/workspace.md index 2f21fb3c..86579fb9 100644 --- a/app/_gateway_entities/workspace.md +++ b/app/_gateway_entities/workspace.md @@ -90,7 +90,7 @@ When a Service or Route is **created** or **modified**, the {{site.base_gateway} Because Workspaces allow users to control {{site.base_gateway}} entities in isolation, users must have the correct permissions to configure a particular Workspace. Users will require either a Super Admin or Admin role to configure Workspaces. The following table details which Workspace permissions each Admin role has: - + {% feature_table %} columns: - title: Super Admin @@ -114,7 +114,7 @@ features: admin: false {% endfeature_table %} - + For more information, see [Roles and permissions](/gateway/roles-and-permissions). From 5972583afc5a2d8f51533be213168a6e319096ec Mon Sep 17 00:00:00 2001 From: Diana <75819066+cloudjumpercat@users.noreply.github.com> Date: Fri, 10 Jan 2025 14:00:15 -0600 Subject: [PATCH 10/10] Apply small fixes --- app/_gateway_entities/workspace.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/app/_gateway_entities/workspace.md b/app/_gateway_entities/workspace.md index 86579fb9..54942411 100644 --- a/app/_gateway_entities/workspace.md +++ b/app/_gateway_entities/workspace.md @@ -26,7 +26,7 @@ faqs: Yes, some entities are global meaning they don't exist in any individual Workspace. For example `ca_certificates`. - q: Can I use Workspaces in Konnect? a: | - No. Instead, {{site.konnect_short_name}} offers the more powerful Consumer Groups [/gateway/entities/consumer-group/] to organize and categorize of Consumers (users or applications) within an API ecosystem + No. Instead, {{site.konnect_short_name}} offers the more powerful [Consumer Groups](/gateway/entities/consumer-group/) to organize and categorize of Consumers (users or applications) within an API ecosystem - q: Can a Workspace share a name with another Workspace? a: | @@ -81,7 +81,7 @@ When a Service or Route is **created** or **modified**, the {{site.base_gateway} * If an equivalent Service or Route is found in a different Workspace, and the host is a wildcard: * If the host field matches in both workspaces, a `409 Conflict` error is returned. * If the host field does not match, the new entity can be created. - * If the host is an absolute value: Issue a `409 Conflict` error. + * If the host is an absolute value, a `409 Conflict` error is returned.