feat(gateway): Datakit and principals - #7099
Conversation
✅ Deploy Preview for kongdeveloper ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
0e5d624 to
ec08246
Compare
cloudjumpercat
left a comment
There was a problem hiding this comment.
Left suggestions! Everything seemed to be working until the end validate steps. Things were missing from the response, like display_name, everything was coming from httpbin.konghq.com as host, and the unauthenticated request gave me a 200 instead of being rejected.
|
|
||
| extended_description: | | ||
| Sign an outgoing JWT in a request header using the authenticated Principal's ID as the subject. | ||
| This example assumes a Consumer has already been authenticated before Datakit runs. |
There was a problem hiding this comment.
| This example assumes a Consumer has already been authenticated before Datakit runs. | |
| This example assumes a Consumer is already authenticated before Datakit runs. |
| Sign an outgoing JWT in a request header using the authenticated Principal's ID as the subject. | ||
|
|
||
| extended_description: | | ||
| Sign an outgoing JWT in a request header using the authenticated Principal's ID as the subject. |
There was a problem hiding this comment.
| Sign an outgoing JWT in a request header using the authenticated Principal's ID as the subject. | |
| Sign an outgoing JWT in a request header using the authenticated [Principal's](/identity/principals/) ID as the subject. |
|
|
||
| ## Create an authorization server in {{site.identity}} | ||
|
|
||
| An authorization server in {{site.identity}} issues the OAuth tokens that callers present to authenticate to your service. |
There was a problem hiding this comment.
| An authorization server in {{site.identity}} issues the OAuth tokens that callers present to authenticate to your service. | |
| An [authorization server](/identity/auth-servers/) in {{site.identity}} issues the OAuth tokens that callers present to authenticate to your service. |
| ## Create an authorization server in {{site.identity}} | ||
|
|
||
| An authorization server in {{site.identity}} issues the OAuth tokens that callers present to authenticate to your service. | ||
| It's recommended that you create different authorization servers for different environments. The authorization server name is unique per each organization and each {{site.konnect_short_name}} region. |
There was a problem hiding this comment.
| It's recommended that you create different authorization servers for different environments. The authorization server name is unique per each organization and each {{site.konnect_short_name}} region. | |
| We recommend that you create different authorization servers for different environments. The authorization server name is unique per each organization and each {{site.konnect_short_name}} region. |
| ## Create the clients | ||
|
|
||
| Create one client per caller. Each client is the machine-to-machine credential that a caller uses to fetch a token. | ||
| {{site.konnect_short_name}} autogenerates the client ID and secret. |
There was a problem hiding this comment.
| {{site.konnect_short_name}} autogenerates the client ID and secret. | |
| In this example, {{site.konnect_short_name}} autogenerates the client ID and secret, but you can also specify them yourself instead. |
feel free to adjust wording, just wanted users to know that autogeneration isn't the only option
| {% endentity_examples %} | ||
|
|
||
| In this configuration: | ||
| * `GET_PRINCIPAL`: Reads the `kong.client.principal` object that the OpenID Connect plugin populates. No input is connected because this is a read-only (get) operation. |
There was a problem hiding this comment.
| * `GET_PRINCIPAL`: Reads the `kong.client.principal` object that the OpenID Connect plugin populates. No input is connected because this is a read-only (get) operation. | |
| * `GET_PRINCIPAL`: Reads the `kong.client.principal` object that the OpenID Connect plugin populates. No input is connected because this is a read-only operation. |
|
|
||
| The response comes from `httpbin.konghq.com`. | ||
| In the response body, find the `complete` event for each node and check: | ||
| * `GET_PRINCIPAL`: `value.value.display_name` is `orders-caller`. |
There was a problem hiding this comment.
I don't see display_name in my output, but I do see the response came from httpbin.konghq.com, so I know it did work.
| -H "X-Datakit-Debug-Trace: true" | ||
| ``` | ||
|
|
||
| The response comes from `httpbun.com`, confirming the request was routed to a different backend. |
There was a problem hiding this comment.
For me, the response for this one was also coming from httpbin.konghq.com.
This was also in my logs: vault.lua:1411 could not retrieve value for reference {vault://env/JWT_HMAC_SECRET} (could not get value from external vault (no value found))
|
|
||
| {% validation unauthorized-check %} | ||
| url: /anything | ||
| {% endvalidation %} |
There was a problem hiding this comment.
This one gave me a 200.
| <!--vale on--> | ||
|
|
||
| Send a request as `orders-caller` again. Once the OpenID Connect plugin's token cache expires, the response comes from `httpbun.com` with no change to your gateway configuration: | ||
|
|
There was a problem hiding this comment.
This one is still coming from httpbin.konghq.com as well.
Description
Fixes #6792
Preview Links
Testing instructions
Kong Konnect
Run:
Required entities
For every decK command, add
--konnect-addr $KONNECT_CONTROL_PLANE_URL -at the end of the command.Checklist
descriptionentry in frontmatter.