Skip to content
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion app/konnect-platform/audit-logs.md
Original file line number Diff line number Diff line change
Expand Up @@ -95,7 +95,7 @@ rows:
{% endtable %}
<!--vale on-->

{{site.konnect_short_name}} retains audit logs for 7 days. After the 7 days, they are permanently deleted and can't be recovered.
{{site.konnect_short_name}} retains audit logs for 7 days. After 7 days, {{site.konnect_short_name}} permanently deletes them and you cannot recover them.

{:.info}
> Dev Portal audit logs don't collect authorization and access events by design. You can view Dev Portal entity creation, edits, and approved state changes from the {{site.konnect_short_name}} audit logs.
Expand Down
6 changes: 3 additions & 3 deletions app/konnect-platform/cmek.md
Original file line number Diff line number Diff line change
Expand Up @@ -63,7 +63,7 @@ To configure CMEK, you need:

1. Provision a new multi-region symmetric key in your AWS account using "Key Managed Service (KMS)". They key should be in the AWS region you intend to use in {{site.konnect_short_name}}. A multi-region key is recommended to replicate the key in multiple regions, which can be used for disaster recovery or compliance purposes.

1. Ensure the following access policy statement is included in your key policy to allow `cc-konnect` role ({{site.konnect_short_name}}) to use your key:
1. Add the following access policy statement to your key policy to allow the `cc-konnect` role ({{site.konnect_short_name}}) to use your key:
```json
{
"Effect": "Allow",
Comment thread
Guaris marked this conversation as resolved.
Outdated
Expand Down Expand Up @@ -98,7 +98,7 @@ When you configure CMEK, you are responsible for the following:

* **Key rotation**:
* AWS KMS takes care of key rotation automatically.
* Manual rotation with a new ARN requires updating the key in {{site.konnect_short_name}}. If the key's ARN changes, data encrypted with the previous key cannot be decrypted in {{site.konnect_short_name}}.
* Manual rotation with a new ARN requires updating the key in {{site.konnect_short_name}}. If the key's ARN changes, {{site.konnect_short_name}} cannot decrypt data encrypted with the previous key.
* **Key revocation**:
* Revoking or deleting your key in AWS KMS renders associated data permanently unreadable.
* **Performance impact**:
Expand All @@ -118,7 +118,7 @@ See the following sections for information about how to manage CMEK keys.

* Rotating keys within AWS KMS (without changing the ARN) is supported automatically.
* If you change the ARN, you must update the key in {{site.konnect_short_name}} manually.
* Data encrypted with the previous key cannot be decrypted and will be lost.
* {{site.konnect_short_name}} cannot decrypt data encrypted with the previous key, and that data will be lost.

### Key revocation

Expand Down
8 changes: 4 additions & 4 deletions app/konnect-platform/compatibility.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,14 +30,14 @@ faqs:
- q: Are the {{site.konnect_short_name}} Control Plane and associated database migrations or upgrades done by Kong Inc.?
a: The {{site.base_gateway}} Control Plane and its dependencies are fully managed by {{site.konnect_short_name}}. As new versions of {{site.base_gateway}} are released, {{site.konnect_short_name}} supports them as long as they are under our [active support schedule](/gateway/version-support-policy/).
- q: Will {{site.konnect_short_name}} Control Plane upgrades always show incompatible messages on the API Gateway page in {{site.konnect_short_name}} if the Data Plane nodes are not the same version as the {{site.konnect_short_name}} Control Plane?
a: An old configuration may still be 100% compatible with older Data Plane nodes and therefore not show any error messages in the {{site.konnect_short_name}} UI. If there are compatibility issues detected when pushing the payload down to the Data Plane, then this will be reflected in the UI.
a: An old configuration may still be 100% compatible with older Data Plane nodes and therefore not show any error messages in the {{site.konnect_short_name}} UI. If {{site.konnect_short_name}} detects compatibility issues when pushing the payload to the Data Plane, the UI displays them.
- q: Will new features be available if the {{site.konnect_short_name}} Control Plane detects incompatible Data Plane nodes?
a: |
New features will not be available for use or consumption on incompatible Data Plane nodes. You will see new features available in the {{site.konnect_short_name}} UI regardless of the Data Plane that is connected to the Control Plane in {{site.konnect_short_name}}. However, when an update payload is pushed to an incompatible Data Plane, the update will be automatically rejected by the Data Plane.
New features will not be available for use or consumption on incompatible Data Plane nodes. You will see new features available in the {{site.konnect_short_name}} UI regardless of the Data Plane that is connected to the Control Plane in {{site.konnect_short_name}}. However, when the Control Plane pushes an update payload to an incompatible Data Plane, the Data Plane automatically rejects the update.
Comment thread
Guaris marked this conversation as resolved.
Outdated

This is managed by a version compatibility layer that checks the payload before the update gets sent to the Data Plane. If there are concerns with the payload, metadata is added to the node. That metadata is what will display incompatibility warnings or errors in the {{site.konnect_short_name}} UI.
A version compatibility layer checks the payload before the Control Plane sends the update to the Data Plane. If the compatibility layer finds concerns with the payload, it adds metadata to the node. {{site.konnect_short_name}} uses that metadata to display incompatibility warnings or errors in the UI.
Comment thread
Guaris marked this conversation as resolved.
Outdated

For example, let's say a parameter is introduced with a new version of a plugin and is available in the {{site.konnect_short_name}} UI. The Data Plane, however, is running an older version of {{site.base_gateway}} and doesn't support the new parameter. If that parameter isn't configured, or is assigned the default value, then no warning or incompatibility metadata will be applied to the node in {{site.konnect_short_name}}, and no warnings or errors will appear.
For example, let's say a parameter is introduced with a new version of a plugin and is available in the {{site.konnect_short_name}} UI. The Data Plane, however, is running an older version of {{site.base_gateway}} and doesn't support the new parameter. If that parameter isn't configured, or is assigned the default value, then {{site.konnect_short_name}} adds no warning or incompatibility metadata to the node, and no warnings or errors appear.
- q: Can I continue to use older versions of configurations as the {{site.konnect_short_name}} Control Plane auto-upgrades?
a: Yes. All decK dumps, or YAML configurations, will continue to work in {{site.konnect_short_name}} after they are synced.
- q: Are there any disruptions if I choose not to upgrade my Data Plane nodes?
Expand Down
2 changes: 1 addition & 1 deletion app/konnect-platform/konnect-labels.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,4 +46,4 @@ Each label must follow these requirements:
You can use labels separately on the Control Plane and Data Plane nodes:
* On the Control Plane, you can set a label for `control plane` and for individual API products.
* On Data Plane nodes, set labels through `kong.conf` or via environment variables using the [`cluster_dp_labels`](/gateway/configuration/#cluster-dp-labels) property.
These labels are exposed through the [`/nodes`](/api/konnect/control-planes-config/#/operations/list-dataplane-nodes) endpoint of the {{site.konnect_short_name}} API.
The {{site.konnect_short_name}} API exposes these labels through the [`/nodes`](/api/konnect/control-planes-config/#/operations/list-dataplane-nodes) endpoint.
6 changes: 3 additions & 3 deletions app/konnect-platform/network.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,13 +46,13 @@ faqs:
When a Data Plane node receives new configuration from the Control Plane, it immediately loads it into memory and also caches it to disk.
The cache location depends on the Gateway version:

* **2.x Gateway** – Configuration is stored in an unencrypted cache file, `config.json.gz`, located in the {{site.base_gateway}} prefix path.
* **3.x Gateway** – Configuration is stored in an unencrypted LMDB database directory, `dbless.lmdb`, also in the {{site.base_gateway}} prefix path.
* **2.x Gateway** – The Data Plane node stores the configuration in an unencrypted cache file, `config.json.gz`, in the {{site.base_gateway}} prefix path.
* **3.x Gateway** – The Data Plane node stores the configuration in an unencrypted LMDB database directory, `dbless.lmdb`, also in the {{site.base_gateway}} prefix path.
- q: What happens if the Control Plane and Data Plane nodes disconnect?
a: |
Data plane nodes use the cached configuration until they can reconnect.
Once reconnected, the Control Plane sends the latest configuration.
It does not queue or replay any older configuration changes.
The Control Plane does not queue or replay any older configuration changes.
- q: Can I restart a Data Plane node if the Control Plane is down or disconnected?
a: |
Yes. Restarting a Data Plane node will load its cached configuration and resume normal function.
Comment thread
Guaris marked this conversation as resolved.
Expand Down
Loading