Entity Review

app/_gateway_entities/certificate.md

@@ -34,7 +34,7 @@ schema:
 
 faqs:
   - q: What's the difference between the Certificate entity and the CA Certificate entity?
-    a: Certificates handle [SSL/TLS termination](/kic/tls-termination-passthrough) for encrypted requests and [CA Certificates](/gateway/entities/ca-certificate/) validate client or server certificates.
+    a: Certificates handle SSL/TLS termination for encrypted requests and [CA Certificates](/gateway/entities/ca-certificate/) validate client or server certificates.
   - q: Is the Certificate entity used in {{site.konnect_short_name}} for data plane nodes as well?
     a: No, the data plane nodes use a [different certificate](/api/konnect/control-planes-config/).
 ---
@@ -44,9 +44,8 @@ faqs:
 A Certificate object represents a public certificate, which is used to validate the sender's authorization and name. It can optionally be paired with the corresponding private key to initiate secure connections and encrypt sensitive data. 
 
 {{site.base_gateway}} can use Certificates in the following ways:
-* Handle [SSL/TLS termination](/kic/tls-termination-passthrough) for encrypted requests
+* Handle SSL/TLS termination for one or more hostnames using the associated [SNI object](/gateway/entities/sni/)
 * Use as a trusted CA store when validating the peer certificate of a client or Service 
-* Tie a certificate and key pair to one or more hostnames using the associated [SNI object](/gateway/entities/sni/)
 
 ## Schema
 

app/_gateway_entities/consumer-group.md

@@ -53,9 +53,6 @@ Consumer Groups enable the organization and categorization of [Consumers](/gatew
 With Consumer Groups, you can scope plugins to specifically defined Consumer Groups and a new plugin instance will be created for each individual Consumer Group, making configurations and customizations more flexible and convenient.
 For all plugins available on the consumer groups scope, see the [Plugin Scopes Reference](/plugins/scopes/).
 
-{:.info}
-> **Note**: Consumer Groups plugin scoping is a feature that was added in {{site.base_gateway}} version 3.4. Running a mixed-version {{site.base_gateway}} cluster (3.4 control plane, and <=3.3 data planes) is not supported when using plugins scoped to Consumer Groups. 
-
 For example, you could define two groups, Gold and Silver, assign different rate limits to them, then process each group using a different plugin:
 
 <!-- vale off -->
@@ -64,46 +61,38 @@ flowchart LR
     A((fa:fa-user Consumers 1-5))
 
     B(<b>Consumer Group Gold</b>
-    10 requests/second
 
     fa:fa-user Consumer 1, fa:fa-user Consumer 2, 
     fa:fa-user Consumer 5 )
 
     C(<b>Consumer Group Silver</b>
-    5 requests/minute
 
     fa:fa-user Consumer 3, fa:fa-user Consumer 4)
 
-    D(Rate Limiting Advanced)
-    E(Request Transformer Advanced)
+    D(Rate Limiting Advanced
+    10 requests/second)
+    E(Rate Limiting Advanced
+    2 requests/second)
     F(<b>Gateway Service</b>
     QR Code Generation)
-    G(<b>Gateway Service</b>
-    OCR)
     H(QR Code Generation 
     service)
-    I(OCR service)
 
     A--> B & C
     subgraph id1 [Kong Gateway]
     direction LR
     B --> D --> F
-        subgraph id2 [Gold route]
-        direction LR
-        D
-        end
-    C --> E --> G
-        subgraph id3 [Silver route]
-        direction LR
-        E
-        end
+    C --> E --> F
     end
 
     F --> H
-    G --> I
 {% endmermaid %}
 <!--vale on -->
 
+Without Consumer Groups there are five Rate Limiting Advanced plugins, once for each consumer. Any time you change the rate limit, you need to update every consumer individually.
+
+Consumer Groups allow you to manage your plugin configuration centrally, and reduce the size of your {{ site.base_gateway }} configuration at the same time. In this example, it's the difference between using two plugins or five plugins. In your production environment, it could be the difference between two plugins and five _million_ plugins.
+
 ## Use cases
 
 Common use cases for Consumer Groups:

app/_gateway_entities/consumer.md

@@ -19,45 +19,40 @@
     a: |
       Credentials are necessary to authenticate Consumers via various authentication mechanisms.
       The credential type depends on which authentication plugin you want to use.
-      <br><br>
+
       For example, a Key Authentication plugin requires an API key, and a Basic Authentication plugin requires a username and password pair.
 
   - q: What is the difference between Consumers and Applications?
     a: |
-      Applications provide developers the ability to get access to APIs managed by {{site.base_gateway}} or {{site.konnect_short_name}}
-      with no interaction from the Kong admin team to generate the required credentials.
-      <br><br>
+      Applications provide developers the ability to get access to APIs managed by {{site.base_gateway}} or {{site.konnect_short_name}} with no interaction from the Kong admin team to generate the required credentials. Applications are managed using the Developer Portal.
+
       With Consumers, the Kong team creates Consumers, generates credentials, and shares them with the developers that need access to the APIs.
-      You can think of Applications as a type of Consumer in Kong that allows developers to automatically obtain credentials for, and subscribe to the required APIs.
 
   - q: What is the difference between Consumers and Developers?
     a: |
-      Developers are real users of the Dev Portal, whereas Consumers are abstractions.
+      A developer is a person that has registered for a Developer Portal. They can create applications and manage credentials themselves.
+
+      Consumers are a part of your {{ site.base_gateway }} configuration and are managed by your administrators.
 
   - q: What is the difference between Consumers and RBAC Users?
     a: |
-      RBAC Users are users of Kong Manager, whereas Consumers are users (real or abstract) of the Gateway itself.
+      RBAC Users are users of Kong Manager, whereas Consumers are users of the services proxied by the Gateway itself.
 
   - q: Which plugins can be scoped to Consumers?
     a: |
-      Certain plugins can be scoped to Consumers (as opposed to Gateway Services, Routes, Consumer Groups, or globally). For example, you might want to
-      configure the Rate Limiting plugin to rate limit a specific Consumer, or use the Request Transformer plugin to edit requests for that Consumer.
+      Most plugins can be scoped to Consumers, with the exception of authentication plugins and plugins that control routing.
+
       You can see the full list in the [plugin scopes compatibility reference](/plugins/scopes/).
 
   - q: Can you scope authentication plugins to Consumers?
     a: |
-      No. You can associate Consumers with an auth plugin by configuring credentials. For example, a Consumer with basic
-      auth credentials will use the Basic Authentication plugin.
-      But that plugin must be scoped to either a Route, Service, or globally, so that the Consumer can access it.
-
+      No. Authentication plugins must be scoped to either a Route, Service, or globally
 
   - q: Can you manage Consumers with decK?
     a: |
-      Yes, you can manage Consumers using decK, but take caution if you have a large number of Consumers.
-      <br><br>
-      If you have many Consumers in your database, don't export or manage them using decK.
-      decK is built for managing entity configuration. It is not meant for end user data,
-      which can easily grow into hundreds of thousands or millions of records.
+      Yes, you can manage Consumers using decK, but take caution if you have a large number of Consumers as the sync time will be high.
+
+      To manage a large number of consumers using decK, we recommend a federated configuration management approach where consumers are placed in to Consumer Groups and managed separately to the rest of your configuration.
 
 tools:
     - admin-api
@@ -78,34 +73,36 @@
 
 ## What is a Consumer?
 
-A Consumer typically refers to an entity that consumes or uses the APIs managed by {{site.base_gateway}}.
+A Consumer is an entity that consumes or uses the APIs managed by {{site.base_gateway}}.
 Consumers can be applications, services, or users who interact with your APIs.
 Since they are not always human, {{site.base_gateway}} calls them Consumers, because they "consume" the service.
 {{site.base_gateway}} allows you to define and manage Consumers, apply access control policies, and monitor their API usage.
 
 Consumers are essential for controlling access to your APIs, tracking usage, and ensuring security.
-They are identified by key authentication, OAuth, or other authentication and authorization mechanisms. 
+They are identified by key authentication, OAuth, or other authentication and authorization mechanisms.
 For example, adding a Basic Auth plugin to a Gateway Service or Route allows it to identify a Consumer, or block access if credentials are invalid.
 
-You can choose to use {{site.base_gateway}} as the primary datastore for Consumers, or you can map the Consumer list 
-to an existing database to keep consistency between {{site.base_gateway}} and your existing primary datastore.
-
 By attaching a plugin directly to a Consumer, you can manage specific controls at the Consumer level, such as rate limits.
 
 {% mermaid %}
 flowchart LR
 
-A(Consumer entity)
-B(Auth plugin)
-C[Upstream service]
-
-Client --> A
-subgraph id1[{{ site.base_gateway }}]
-direction LR
-A--Credentials-->B
+Consumer(Consumer entity)
+Service(Gateway Service)
+Auth(Auth plugin)
+Upstream[Upstream service]
+RL["Per-consumer
+Rate Limiting Plugin applied"]
+
+Client --> Authenticate
+subgraph Authenticate ["Consumer Identity Added"]
+    direction TB
+    Service --> Auth
+    Auth-->Consumer
 end
+Authenticate --> RL
+RL --> Upstream
 
-B-->C
 {% endmermaid %}
 
 ## Use cases for Consumers
@@ -114,9 +111,9 @@
 
 |Use case | Description|
 |---------|------------|
-|Authentication | Client authentication is the most common reason for setting up a Consumer. If you're using an authentication plugin, you'll need a Consumer with credentials.|
-|Consumer Groups | Group Consumers by sets of criteria and apply certain rules to them.|
-|Rate limiting | Rate limit specific Consumers based on tiers.|
+| Authentication | Client authentication is the most common reason for setting up a Consumer. If you're using an authentication plugin, you'll need a Consumer with credentials. |
+| Rate limiting | Rate limit specific Consumers based on tiers. |
+| Transformation | Add or remove values from response bodies based on the Consumer |
 
 ## Schema
 

app/_gateway_entities/group.md

@@ -47,7 +47,7 @@ The Group resource can also be used to integrate identity providers like Okta wi
 
 ## Service directory mapping
 
-With service directory mapping, Groups can be mapped to [RBAC Roles](/gateway/entities/rbac/#role-configuration). When a user logs in to Kong Manager, they are identified with their Admin username and authenticated with user credentials from a service directory, like [LDAP](/plugins/ldap-auth/). The service directory creates a relationship with the associated RBAC Roles that are defined in {{site.base_gateway}}. 
+With service directory mapping, Groups can be mapped to [RBAC Roles](/gateway/entities/rbac/#role-configuration). When a user logs in to Kong Manager, they are identified with their Admin username and authenticated with user credentials from a service directory, like [LDAP](https://docs.konghq.com/gateway/latest/kong-manager/auth/ldap/service-directory-mapping/). The service directory creates a relationship with the associated RBAC Roles that are defined in {{site.base_gateway}}. 
 This happens in the following order: 
 
 
@@ -56,7 +56,7 @@ This happens in the following order:
 3. Groups are associated with an external directory.
 4. Permissions are assigned to {{site.base_gateway}} users based on Group assignment.
 
-For more information, read the [LDAP](/plugins/ldap-auth/) documentation.
+For more information, read the [Mapping LDAP Service Directory Groups to Kong Roles](https://docs.konghq.com/gateway/latest/kong-manager/auth/ldap/service-directory-mapping/) documentation.
 
 
 ## Schema

app/_gateway_entities/license.md

@@ -68,12 +68,12 @@ features:
   - title: License File
     url: /gateway/entities/license/#deploy-a-license-with-a-file-on-the-node-filesystem-licensejson
     traditional: true
-    hybrid: false
+    hybrid: true
     dbless: true
   - title: Environment variable
     url: /gateway/entities/license/#deploy-a-license-with-an-environment-variable
     traditional: true
-    hybrid: false
+    hybrid: true
     dbless: true
 {% endfeature_table %}
 
@@ -91,17 +91,17 @@ data:
   payload: "{\"license\":{\"payload\":{\"admin_seats\":\"1\",\"customer\":\"Example Company, Inc\",\"dataplanes\":\"1\",\"license_creation_date\":\"2017-07-20\",\"license_expiration_date\":\"2017-07-20\",\"license_key\":\"00141000017ODj3AAG_a1V41000004wT0OEAU\",\"product_subscription\":\"Konnect Enterprise\",\"support_plan\":\"None\"},\"signature\":\"6985968131533a967fcc721244a979948b1066967f1e9cd65dbd8eeabe060fc32d894a2945f5e4a03c1cd2198c74e058ac63d28b045c2f1fcec95877bd790e1b\",\"version\":\"1\"}}"
 {% endentity_example %}
 
-[Reload](/how-to/restart-kong-gateway-container/) the {{site.base_gateway}} nodes after adding or updating a License.
-
 {% endnavtab %}
 {% navtab "license.json" %}
 ### Deploy a License with `license.json`
 
 The license data must contain straight quotes to be considered valid JSON (`'` and `"`, not `’` or `“`). Kong searches for the License by default in `/etc/kong/license.json`.
 
+The control plane **does not** propagate the License to data plane nodes. You **must** add the License to each data plane node, and each node **must** start with the License. The License can't be added after starting the node.
+
 1. Save your License to a file named `license.json`.  
 1. Copy the license file to the `/etc/kong`.
-1. [Reload](/how-to/restart-kong-gateway-container/) the {{site.base_gateway}} nodes to apply the license by running `kong reload` from within the container.
+1. [Restart](/how-to/restart-kong-gateway-container/) the {{site.base_gateway}} nodes to apply the license by running `kong restart` from within the container.
 {% endnavtab %}
 {% navtab "Environment variable" %}
 ### Deploy a License as an environment variable 

app/_gateway_entities/rbac.md

@@ -3,8 +3,7 @@ title: RBAC
 content_type: reference
 products:
   - gateway
-tiers: 
-  - enterprise
+tier: enterprise
 tools:
     - admin-api
 entities:
@@ -34,11 +33,9 @@ RBAC in {{site.base_gateway}} conforms to the following core principles:
 * In {{site.base_gateway}} there are Users
 * Every user has a Role
 * Roles are assigned Permissions
-* Every Role belongs to a [Group](/gateway/entities/group/)
 * A Group is a collection of Roles
 
-{{site.base_gateway}} uses a precedence model, from most specificity to least specificity, to determine if a user has access to an endpoint.
-
+{{site.base_gateway}} uses a [precedence model](#rbac-precedence-order), from most specificity to least specificity, to determine if a user has access to an endpoint.
 
 ## What are Permissions?
 
@@ -199,18 +196,4 @@ You can also automate the creation of Admins. For more information, see [creatin
 
 ## Schema
 
-{% entity_schema %}
-
-## Create an RBAC user
-
-Creating an RBAC User requires [RBAC to be enabled](#enable-rbac) for {{site.base_gateway}}.
-
-{% entity_example %}
-type: rbac
-data:
-  name: my-user
-  user_token: exampletoken
-headers:
-  admin-api:
-    - "Kong-Admin-Token: $ADMIN_TOKEN"
-{% endentity_example %}
+{% entity_schema %}