client_certificate docs vs declarative API inconsistency

[meesvandongen]

Kong version ($ kong version)

2.8

Current Behavior

The client_certificate in the docs suggest that an object should be sent with an id key.

"client_certificate": {"id":"c97b1292-b5b0-4d51-95ee-cbcfaf104a3a"}

But in the declarative config I am not able to use this.

_format_version: '1.1'
services:
  - client_certificate:
      id:  c97b1292-b5b0-4d51-95ee-cbcfaf104a3a

Expected Behavior

I would expect the declarative API (using DecK) and the Admin API to behave the same.

Anything else?

It does work when omitting the id attribute.

_format_version: '1.1'
services:
  - client_certificate: c97b1292-b5b0-4d51-95ee-cbcfaf104a3a

So in the end it is not really a problem for me. I am submitting this issue though as I have not seen this behavior documented elsewhere.

[Yainsun]

Thanks @meesvandongen , I faced below error when check declarative file and your solution save me.

$ kong config -c /etc/kong/kong.conf parse kong.test.yaml Error: Failed parsing: in 'services': in 'kong-test': - in entry 1 of 'kong-test': invalid reference 'client_certificate: {"id":"00000000-0000-0000-0000-000000000002"}' (no such entry in 'certificates')

[pravynandas]

+1.

Quick fix worked.

[kikito]

hi, @meesvandongen, could you include a link to the docs that you think are wrong?

[meesvandongen]

@kikito For example here https://docs.konghq.com/gateway/latest/admin-api/#service-object

    "client_certificate": {"id":"4e3ad2e4-0bc4-4638-8e34-c84a417ba39b"},

[StarlightIbuki]

It seems the PR fixed the issue. If that's not the case please feel free to reopen it.