|
63 | 63 | { |
64 | 64 | "title": "VAULTS", |
65 | 65 | "start": 1884, |
66 | | - "end": 2119, |
| 66 | + "end": 2117, |
67 | 67 | "description": "A secret is any sensitive piece of information required for API gateway\noperations. Secrets may be part of the core Kong Gateway configuration,\nused in plugins, or part of the configuration associated with APIs serviced\nby the gateway.\n\nSome of the most common types of secrets used by Kong Gateway include:\n\n- Data store usernames and passwords, used with PostgreSQL and Redis\n- Private X.509 certificates\n- API keys\n\nSensitive plugin configuration fields are generally used for authentication,\nhashing, signing, or encryption. Kong Gateway lets you store certain values\nin a vault. Here are the vault specific configuration options.\n" |
68 | 68 | }, |
| 69 | + { |
| 70 | + "title": "AI", |
| 71 | + "start": 2118, |
| 72 | + "end": 2123, |
| 73 | + "description": "" |
| 74 | + }, |
69 | 75 | { |
70 | 76 | "title": "TUNING & BEHAVIOR", |
71 | | - "start": 2120, |
72 | | - "end": 2256, |
| 77 | + "start": 2124, |
| 78 | + "end": 2260, |
73 | 79 | "description": "" |
74 | 80 | }, |
75 | 81 | { |
76 | 82 | "title": "MISCELLANEOUS", |
77 | | - "start": 2257, |
78 | | - "end": 2378, |
| 83 | + "start": 2261, |
| 84 | + "end": 2382, |
79 | 85 | "description": "Additional settings inherited from lua-nginx-module allowing for more\nflexibility and advanced usage.\n\nSee the lua-nginx-module documentation for more information:\nhttps://github.com/openresty/lua-nginx-module\n" |
80 | 86 | }, |
81 | 87 | { |
82 | 88 | "title": "KONG MANAGER", |
83 | | - "start": 2379, |
84 | | - "end": 2654, |
| 89 | + "start": 2383, |
| 90 | + "end": 2658, |
85 | 91 | "description": "\nThe Admin GUI for Kong Enterprise.\n\n" |
86 | 92 | }, |
87 | 93 | { |
88 | 94 | "title": "Konnect", |
89 | | - "start": 2655, |
90 | | - "end": 2661, |
| 95 | + "start": 2659, |
| 96 | + "end": 2665, |
91 | 97 | "description": "" |
92 | 98 | }, |
93 | 99 | { |
94 | 100 | "title": "Analytics for Konnect", |
95 | | - "start": 2662, |
96 | | - "end": 2682, |
| 101 | + "start": 2666, |
| 102 | + "end": 2686, |
97 | 103 | "description": "" |
98 | 104 | }, |
99 | 105 | { |
100 | 106 | "title": "ADMIN SMTP CONFIGURATION", |
101 | | - "start": 2683, |
102 | | - "end": 2697, |
| 107 | + "start": 2687, |
| 108 | + "end": 2701, |
103 | 109 | "description": "" |
104 | 110 | }, |
105 | 111 | { |
106 | 112 | "title": "GENERAL SMTP CONFIGURATION", |
107 | | - "start": 2698, |
108 | | - "end": 2748, |
| 113 | + "start": 2702, |
| 114 | + "end": 2752, |
109 | 115 | "description": "" |
110 | 116 | }, |
111 | 117 | { |
112 | 118 | "title": "DATA & ADMIN AUDIT", |
113 | | - "start": 2749, |
114 | | - "end": 2794, |
| 119 | + "start": 2753, |
| 120 | + "end": 2798, |
115 | 121 | "description": "When enabled, Kong will store detailed audit data regarding Admin API and\ndatabase access. In most cases, updates to the database are associated with\nAdmin API requests. As such, database object audit log data is tied to a\ngiven HTTP request via a unique identifier, providing built-in association of\nAdmin API and database traffic.\n\n" |
116 | 122 | }, |
117 | 123 | { |
118 | 124 | "title": "ROUTE COLLISION DETECTION/PREVENTION", |
119 | | - "start": 2795, |
120 | | - "end": 2842, |
| 125 | + "start": 2799, |
| 126 | + "end": 2846, |
121 | 127 | "description": "" |
122 | 128 | }, |
123 | 129 | { |
124 | 130 | "title": "DATABASE ENCRYPTION & KEYRING MANAGEMENT", |
125 | | - "start": 2843, |
126 | | - "end": 3071, |
| 131 | + "start": 2847, |
| 132 | + "end": 3075, |
127 | 133 | "description": "When enabled, Kong will transparently encrypt sensitive fields, such as consumer\ncredentials, TLS private keys, and RBAC user tokens, among others. A full list\nof encrypted fields is available from the Kong Enterprise documentation site.\nEncrypted data is transparently decrypted before being displayed to the Admin\nAPI or made available to plugins or core routing logic.\n\nWhile this feature is GA, do note that we currently do not provide normal semantic\nversioning compatibility guarantees on the keyring feature's APIs in that Kong may\nmake a breaking change to the feature in a minor version. Also note that\nmismanagement of keyring data may result in irrecoverable data loss.\n\n" |
128 | 134 | }, |
129 | 135 | { |
130 | 136 | "title": "CLUSTER FALLBACK CONFIGURATION", |
131 | | - "start": 3072, |
132 | | - "end": 3119, |
| 137 | + "start": 3076, |
| 138 | + "end": 3123, |
133 | 139 | "description": "" |
134 | 140 | }, |
135 | 141 | { |
136 | 142 | "title": "REQUEST DEBUGGING", |
137 | | - "start": 3120, |
138 | | - "end": 3182, |
| 143 | + "start": 3124, |
| 144 | + "end": 3186, |
139 | 145 | "description": "Request debugging is a mechanism that allows admins to collect the timing of\nproxy path requests in the response header (X-Kong-Request-Debug-Output)\nand optionally, the error log.\n\nThis feature provides insights into the time spent within various components of Kong,\nsuch as plugins, DNS resolution, load balancing, and more. It also provides contextual\ninformation such as domain names tried during these processes.\n\n" |
140 | 146 | } |
141 | 147 | ], |
|
1278 | 1284 | "description": "Time (in seconds) for which stale secrets\nfrom the Azure Key Vault should be resurrected\nfor when they cannot be refreshed (e.g., the\nthe vault is unreachable). When this TTL\nexpires, a new attempt to refresh the stale\nsecrets will be made.\n", |
1279 | 1285 | "sectionTitle": "VAULTS" |
1280 | 1286 | }, |
| 1287 | + "ai_mcp_listener_enabled": { |
| 1288 | + "defaultValue": "on", |
| 1289 | + "description": "Enable or disable the MCP unix socket listener.\n", |
| 1290 | + "sectionTitle": "AI" |
| 1291 | + }, |
1281 | 1292 | "worker_consistency": { |
1282 | 1293 | "defaultValue": "eventual", |
1283 | 1294 | "description": "Defines whether this node should rebuild its\nstate synchronously or asynchronously (the\nbalancers and the router are rebuilt on\nupdates that affect them, e.g., updates to\nroutes, services, or upstreams via the admin\nAPI or loading a declarative configuration\nfile). (This option is deprecated and will be\nremoved in future releases. The new default\nis `eventual`.)\n\nAccepted values are:\n\n- `strict`: the router will be rebuilt\n synchronously, causing incoming requests to\n be delayed until the rebuild is finished.\n (This option is deprecated and will be removed\n in future releases. The new default is `eventual`)\n- `eventual`: the router will be rebuilt\n asynchronously via a recurring background\n job running every second inside of each\n worker.\n\nNote that `strict` ensures that all workers\nof a given node will always proxy requests\nwith an identical router, but increased\nlong-tail latency can be observed if\nfrequent routes and services updates are\nexpected.\nUsing `eventual` will help prevent long-tail\nlatency issues in such cases, but may\ncause workers to route requests differently\nfor a short period of time after routes and\nservices updates.\n", |
|
0 commit comments