{"id":1111,"date":"2021-07-15T16:08:41","date_gmt":"2021-07-15T14:08:41","guid":{"rendered":"https:\/\/loeilduse.fr\/?p=1111"},"modified":"2021-07-15T16:13:28","modified_gmt":"2021-07-15T14:13:28","slug":"create-a-ldaps-self-signed-certificates-for-pinniped","status":"publish","type":"post","link":"https:\/\/loeilduse.fr\/?p=1111&lang=en","title":{"rendered":"Create a LDAPS self-signed certificates for Pinniped"},"content":{"rendered":"

In order to simplify the authentication of Kubernetes clusters operating on different clouds, VMware has developed the Pinniped project accessible in Opensource. Pinniped has been integrated by default into the<\/span><\/span>\u00a0VMware Tanzu Kubernetes Grid<\/a> (TKG) offering since version 1.3, replacing the <\/span><\/span>Gangway<\/a>. inniped allows authentication from OIDC or LDAP sources. In the case of LDAP source, Pinniped does not connect directly to LDAP but currently relies on the <\/span><\/span> Dex<\/a> component as Gangway already did.<\/span><\/span><\/span><\/p>\n

When a user runs a Kubernetes command for the first time or after a certain period of inactivity, they are prompted to authenticate only once with their corporate credentials and can then consume multiple Kubernetes clusters. <\/span><\/span><\/p>\n

I wanted to test this functionality in my lab with an LDAPS \/ Active Directory server running Windows 2019 and I quickly encountered the eternal problem of certificates not signed by a known authority. So I had to create a certificate that is recognized by the Active Directory server. Searching for hours on the internet, I ended up finding an article by<\/span><\/span>\u00a0Peter Mescalchin<\/a> that worked on the first try:<\/span><\/span> Enable LDAP over SSL (LDAPS) for Microsoft Active Directory servers. – bl.ocks.org.<\/a><\/span><\/p>\n

However, when I wanted to use this procedure with Pinniped, it did not work because the SAN (Subject Alternative Name) information was not present in the certificate. By crossing several articles on the subject, I was able to adapt Peter Mescalchin’s solution so that the certificates integrate the SAN information. It gives this: <\/span><\/span><\/p>\n

Creation of the Root certificate<\/span><\/span><\/strong><\/span><\/p>\n

Via OpenSSL<\/span> <\/em>(I used a Linux Ubuntu) create a private key (ca.key<\/span><\/em> in my example) to be able to then create the root certificate (ca.crt<\/em><\/span> in my example). The first command will ask you for a password and the second for your organization information.<\/span><\/span><\/p>\n

$ openssl genrsa -aes256 -out ca.key 4096
\n<\/em>$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt<\/em><\/span><\/p>\n

 <\/p>\n

Import the Root certificate on the AD server<\/strong> <\/span><\/span><\/p>\n

From the AD server, type the command certlm<\/em> <\/span>or via Control Pannel, type computer certificates in the search bar: <\/span><\/span><\/p>\n

Be careful to choose \u201cManage computer certificates\u201d and not \u201cManage user certificates\u201d <\/span><\/span><\/p>\n

\"\"<\/span><\/p>\n

Import the previously generated ca.crt<\/em><\/span> in the “Trusted Root Certification Authorities \\ Certificates” section<\/span><\/span><\/p>\n

\"\"<\/span><\/p>\n

\u00a0<\/strong><\/span><\/p>\n

Creation of the Client certificate<\/strong> <\/span><\/span><\/p>\n

Still from the Active Directory server, create a file, in our example it has the name request.inf<\/span><\/em>. In red, I have made changes from the original procedure to add the SAN information. Be careful to put the FQDN of the AD server in CN<\/span><\/em>. The values \u200b\u200bof _continue_ = “dns”<\/span><\/em><\/span><\/strong> and _continue_ = “ip-address”<\/span><\/strong><\/span><\/em> correspond to the SAN values, the other possible values \u200b\u200bto reference the AD server.<\/span><\/span><\/p>\n

[<\/em>Version<\/em>]
\n<\/em>Signature=”$Windows NT$”<\/em><\/span><\/p>\n

[NewRequest]<\/span>
\n<\/em>Subject = “CN=<\/span><\/em>ad-server.cpod-velocity.az-fkd.cloud-garage.net<\/em><\/strong><\/span>“<\/span>
\n<\/em>KeySpec = 1
\n<\/em>KeyLength = 2048
\n<\/em>Exportable = TRUE
\n<\/em>MachineKeySet = TRUE
\n<\/em>SMIME = FALSE
\n<\/em>PrivateKeyArchive = FALSE
\n<\/em>UserProtected = FALSE
\n<\/em>UseExistingKeySet = FALSE
\n<\/em>ProviderName = “Microsoft RSA SChannel Cryptographic Provider”
\n<\/em>ProviderType = 12
\n<\/em>RequestType = PKCS10
\n<\/em>KeyUsage = 0xa0<\/em><\/span><\/p>\n

[EnhancedKeyUsageExtension]
\n<\/em>OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication<\/em><\/span><\/p>\n

[Extensions]
\n<\/em><\/strong>; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension.
\n<\/em><\/strong>2.5.29.17 = “{text}”
\n<\/em><\/strong>_continue_ = “dns=ad-server&”
\n<\/em><\/strong>_continue_ = “dns=ad-server.cpod-velocity.az-fkd.cloud-garage.net&”
\n<\/em><\/strong>_continue_ = “dns=cloud-garage.net&”
\n<\/em><\/strong>_continue_ = “ipaddress=172.17.13.9&”<\/em><\/strong><\/span><\/p>\n

Generate the client.csr<\/em><\/span> file with the command below:<\/span><\/span><\/p>\n

c:\\> certreq -new request.inf client.csr<\/em><\/span><\/p>\n

From the Linux machine: <\/span><\/span><\/p>\n

Create an extension file, in our example it has the name v3ext.txt<\/span><\/em>. In red, I have made the changes from the initial procedure to add the SAN information under the heading v3_ca<\/span> <\/em>which will be referenced in the next order.<\/span><\/span><\/p>\n

keyUsage=digitalSignature,keyEncipherment
\n<\/em>extendedKeyUsage=serverAuth
\n<\/em>subjectKeyIdentifier=hash<\/em><\/span><\/p>\n

# These extensions are added when ‘ca’ signs a request.
\n<\/em><\/strong>[ v3_ca ]
\n<\/em><\/strong>subjectAltName = @alt_names<\/em><\/strong><\/span><\/p>\n

[ alt_names ]
\n<\/em><\/strong>DNS.1 = ad-server.cpod-velocity.az-fkd.cloud-garage.net
\n<\/em><\/strong>DNS.2 = ad-server
\n<\/em><\/strong>IP.1 = 172.17.13.9<\/em><\/strong><\/span><\/p>\n

Still from the Linux machine, create the client.crt<\/span><\/em> certificate from the files generated in the previous steps ca.crt<\/span><\/em>, ca.key<\/span><\/em>, client.csr<\/span><\/em> and v3ext.txt<\/span><\/em>, in red which has been added compared to the command outcome of the initial procedure<\/span><\/span><\/p>\n

$ openssl x509 -req -days 3650 -in client.csr -CA ca.crt -CAkey ca.key -extfile v3ext.txt -set_serial 01 -out client.crt<\/em> -extensions v3_ca<\/strong><\/em><\/span><\/span><\/p>\n

\u00a0<\/em><\/span><\/p>\n

To verify the presence of SAN information<\/span><\/span><\/p>\n

$ openssl x509 -in client.crt -text
\n<\/em>\u00a0…..
\n<\/em>X509v3 extensions:
\n<\/em><\/strong>\u00a0\u00a0\u00a0 \u00a0\u00a0<\/em><\/strong>X509v3 Subject Alternative Name:
\n<\/em><\/strong>\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0DNS:ad-server.cpod-velocity.az-fkd.cloud-garage.net, DNS:ad-server, IP Address:172.17.13.9<\/em><\/strong><\/span><\/span><\/p>\n

\u00a0<\/strong><\/span><\/p>\n

Import the Client certificate<\/strong> <\/span><\/span><\/p>\n

From the AD server<\/span><\/span><\/p>\n

C:\\> certreq -accept client.crt<\/em><\/span><\/p>\n

The certificate should appear in “Personal \\ Certificates”<\/span><\/span><\/p>\n

\"\"<\/span><\/p>\n

For the certificate to be taken into account, you must either restart the AD server or force LDAPS to load the certificate with the procedure below: <\/span><\/span><\/p>\n

Still from the AD server, create a text file, in our example it is called ldap-renewservercert.txt<\/span><\/em> with the content below (note the end of the file includes a line with a – (a dash):<\/span><\/span><\/p>\n

dn:
\n<\/em>changetype: modify
\n<\/em>add: renewServerCertificate
\n<\/em>renewServerCertificate: 1
\n<\/em>–<\/em><\/span><\/p>\n

Then type the command below:<\/span><\/span><\/p>\n

c:\\> ldifde -i -f ldap-renewservercert.txt<\/em><\/span><\/p>\n

To test the taking into account, use the ldp.exe<\/span> <\/em>utility by selecting port 636<\/span> <\/em>(or another if specific) and checking the SSL<\/span> <\/em>box.<\/span><\/span><\/p>\n

\"\"<\/span><\/p>\n

Once all the procedure is done, you have to recover the ca.crt<\/span><\/em> generated in the first step to give it to Pinniped. This can be done either when the TKG management cluster is created or subsequently. <\/span><\/span><\/p>\n

If the management cluster has not yet been created:<\/span><\/span><\/strong><\/span><\/p>\n

$ tanzu management-cluster create –ui<\/span>
\n(there are two dashes before the ui argument but WordPress only displays one)<\/span><\/span>
\n<\/em><\/span><\/p>\n

In my test I chose vSphere as the platform, at the identity manager step it will be necessary to copy the certificate in the ROOT CA part<\/span><\/span><\/p>\n

\"\"<\/u><\/span><\/p>\n

If the TKG management cluster has already been created and you want to update it:<\/span><\/span><\/strong><\/span><\/p>\n

From the Kubernetes context of the manager cluster, encrypt the Root certificate of the AD server with the base64 command and get the result:<\/span><\/span><\/p>\n

$ base64 -w 0 ca.crt<\/em><\/span><\/p>\n

Modify the certificate in the dex<\/span> <\/em>configmap by the result of the previous command:<\/span><\/span><\/p>\n

$ kubectl edit configmap -n tanzu-system-auth dex
\n<\/em># Please edit the object below. Lines beginning with a ‘#’ will be ignored,
\n<\/em># and an empty file will abort the edit. If an error occurs while saving this file will be
\n<\/em># reopened with the relevant failures.
\n<\/em>#
\n<\/em>apiVersion: v1
\n<\/em>data:
\n<\/em>\u00a0 config.yaml: |
\n<\/em>\u00a0\u00a0\u00a0 issuer: https:\/\/172.17.13.10:30167
\n<\/em>\u00a0\u00a0\u00a0 frontend:
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 theme: tkg
\n<\/em>\u00a0\u00a0\u00a0 <\/em>web:
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 https: 0.0.0.0:5556
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 tlsCert: \/etc\/dex\/tls\/tls.crt
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 tlsKey: \/etc\/dex\/tls\/tls.key
\n<\/em>\u00a0\u00a0\u00a0 <\/em>expiry:
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 signingKeys: 90m
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 idTokens: 5m
\n<\/em>\u00a0\u00a0\u00a0 logger:
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 level: info
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 format: json
\n<\/em>\u00a0\u00a0\u00a0 staticClients:
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 – id: pinniped-client-id
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 name: pinniped-client-id
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 redirectURIs:
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 – https:\/\/172.17.13.10:31234\/callback
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 secret: 089db7e23b19cb628ba841b17cc32ea4
\n<\/em>\u00a0\u00a0\u00a0 connectors:
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 – type: ldap
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 id: ldap
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 name: LDAP
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u00a0config:
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 host: ad-server.cpod-velocity.az-fkd.cloud-garage.net:636
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 insecureSkipVerify: false
\nbindDN: cn=administrator,cn=Users,dc=velocity,dc=local
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 bindPW: $BIND_PW_ENV_VAR
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 usernamePrompt: LDAP Username
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/em>rootCAData:
\nLS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUdQekNDQkNlZ0F3SUJBZ0lVU2tQd0JPazVYRVFLRlpydXdwZXBoeTlINndzd0RRWUpLb1pJaHZjTkFRRUwKQlFBd2dhNHhDek<\/span><\/strong>
\nKQmdOVkJBWVRBa1pTTVF3d0NnWURWUVFJREFOSlJFWXhEakFNQmdOVkJBY01CVkJoY21segpNUlF3RWdZRFZRUUtEQXRNYjJWcGJDMWtkUzFUUlRFTE1Ba0dBMVVFQ3d3Q1UwVXhPRE<\/span><\/strong>
\nEyQmdOVkJBTU1MMkZrCkxYTmxjblpsY2k1amNHOWtMWFpsYkc5amFYUjVMbUY2TFdaclpDNWpiRzkxWkMxbllYSmhaMlV1Ym1WME1TUXcKSWdZSktvWklodmNOQVFrQkZoVm1ZbVZ1Y<\/span><\/strong>
\n21WcVpHRnNRSFp0ZDJGeVpTNWpiMjB3SGhjTk1qRXdOekEzTURjeQpNekl5V2hjTk16RXdOekExTURjeU16SXlXakNCcmpFTE1Ba0dBMVVFQmhNQ1JsSXhEREFLQmdOVkJBZ01BMGxFClJqRU9NQXdHQTFVRUJ3d0ZVR0Z5YVhNeEZEQVNCZ05WQkFvTUMweHZaV2xzTFdSMUxWTkZNUXN3Q1FZRFZRUUwKREFKVFJURTRNRFlHQTFVRUF3d3ZZV1F0YzJWeWRtVnlMbU53YjJ<\/span><\/strong>
\nRdGRtVnNiMk5wZEhrdVlYb3RabXRrTG1OcwpiM1ZrTFdkaGNtRm5aUzV1WlhReEpEQWlCZ2txaGtpRzl3MEJDUUVXRldaaVpXNXlaV3BrWVd4QWRtMTNZWEpsCkxtTnZiVENDQWlJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dJUEFEQ0NBZ29DZ2dJQkFMaWx0WE81WkxNOFRzZ0YKMXFxRFFURi9xV1EzTGkvalU2ZFJqM1VMLys2YitRL0VUVjdIb2VLMi9hK09UdHlRbzY4c<\/span><\/strong>
\nk9ySTVJRjNNWlJqKwpzU0JuWC9SejczczYvVjArWXhJTFozSmNNenlWUzZtR1ZhNTZBTmFZRFRqSkErUzF5enZJczFpZXdMWDR2YlFzCnJRdFE2NVphb3NYbFlMSWpxdzZCY01TZUlX<\/span><\/strong>
\nNUlUWitlUVF3emlkN2t5ZFBYNDdTBSSm1vR\u2026..1<\/span><\/strong>
\n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u2026.<\/em><\/span><\/p>\n

Relaunch the dex pod in the tanzu-system-auth<\/span><\/em> namespace to take the change into account.<\/span><\/span><\/p>\n

 <\/p>\n

Once the management cluster has the right certificate<\/strong> <\/span><\/span><\/p>\n

From there, create a workload cluster:<\/span><\/span><\/p>\n

$ tanzu cluster create my-cluster -f <fichier-environnement><\/em><\/span><\/p>\n

Import the administration Kubeconfig of the created workload cluster:<\/span><\/span><\/p>\n

$ tanzu cluster kubeconfig get my-cluster –admin
\n<\/em>(there are two dashes before the admin argument but WordPress only displays one)<\/span><\/span><\/span><\/p>\n

Connect to the workload cluster with the admin context, as admin no need for an account:<\/span><\/span><\/p>\n

$ kubectl use-context my-cluster-admin<\/strong>@my-cluster<\/em><\/span><\/p>\n

Create a cluster role binding with the role that interests you (here cluster-admin<\/span><\/em>) for the desired users, this will allow the user to use this cluster once authenticated: <\/span><\/span><\/p>\n

$ kubectl create clusterrolebinding admin-fbenrejdal\u00a0 –clusterrole cluster-admin –user fbe@velocity.local<\/span>
\n(there are two dashes before the clusterrole and user arguments but WordPress only displays one)<\/span><\/span>
\n<\/em><\/span><\/p>\n

Export the workload cluster kubeconfig, this is the kubeconfig that will need to be passed to users, it has no admin context and will require user authentication. The user will consume this cluster according to the rights defined in clusterrolebinding from the previous step:<\/span><\/span><\/p>\n

$ tanzu cluster kubeconfig get my-cluster –export-file my-cluster-kubeconfig
\n<\/em>(there are two dashes before the export argument but WordPress only displays one)<\/span><\/span><\/span><\/p>\n

Issue a kubernetes command with the generated kubeconfig file, which will launch the browser for authentication:<\/span><\/span><\/p>\n

$ kubectl get pods -A –kubeconfig my-cluster-kubeconfig<\/span>
\n(there are two dashes before the kubeconfig argument but WordPress only displays one)<\/span><\/span>
\n<\/em><\/span><\/p>\n

You should be redirected to a browser with a web page asking for your username and password:<\/span> <\/span><\/p>\n

\"\"<\/span><\/p>\n

Once entered, you will get the result of your last command:<\/span><\/span><\/p>\n

\"\"<\/span><\/p>\n

The result of the previously command should be displayed:<\/span> <\/span><\/p>\n

NAMESPACE NAME READY STATUS RESTARTS AGE<\/span><\/em>
\nkube-system antrea-agent-q9xpg 2\/2 Running 0 7d15h<\/span><\/em>
\nkube-system antrea-agent-qlmj8 2\/2 Running 0 7d15h<\/span><\/em>
\nkube-system antrea-controller-6bb57bd84-6cj58 1\/1 Running 0 7d15h<\/span><\/em>
\nkube-system coredns-68d49685bd-bjcps 1\/1 Running 0 7d15h<\/span><\/em>
\nkube-system coredns-68d49685bd-vttdw 1\/1 Running 0 7d15h<\/span><\/em>
\nkube-system etcd-my-cluster-control-plane-48n9f 1\/1 Running 0 7d15h<\/span><\/em>
\nkube-system kube-apiserver-my-cluster-control-plane-48n9f 1\/1 Running 0 7d15h<\/span><\/em>
\nkube-system kube-controller-manager-my-cluster-control-plane-48n9f 1\/1 Running 0 7d15h<\/span><\/em>
\nkube-system kube-proxy-dntrc 1\/1 Running 0 7d15h<\/span><\/em>
\nkube-system kube-proxy-k5m9g 1\/1 Running 0 7d15h<\/span><\/em>
\nkube-system kube-scheduler-my-cluster-control-plane-48n9f 1\/1 Running 0 7d15h<\/span><\/em>
\nkube-system kube-vip-my-cluster-control-plane-48n9f 1\/1 Running 0 7d15h<\/span><\/em>
\nkube-system metrics-server-66cb4fb659-xlprc 1\/1 Running 0 7d15h<\/span><\/em>
\nkube-system vsphere-cloud-controller-manager-vmfwl 1\/1 Running 1 7d15h<\/span><\/em>
\nkube-system vsphere-csi-controller-bd8b6cc8c-8ljl8 6\/6 Running 0 7d15h<\/span><\/em>
\nkube-system vsphere-csi-node-6xqf5 3\/3 Running 0 7d15h<\/span><\/em>
\nkube-system vsphere-csi-node-vmbmq 3\/3 Running 0 7d15h<\/span><\/em>
\npinniped-concierge pinniped-concierge-dcd587f97-lk9n5 1\/1 Running 0 7d15h<\/span><\/em>
\npinniped-concierge pinniped-concierge-dcd587f97-zrnb7 1\/1 Running 0 7d15h<\/span><\/em>
\npinniped-concierge pinniped-concierge-kube-cert-agent-8a8e3e38 1\/1 Running 0 7d15h<\/span><\/em>
\npinniped-supervisor pinniped-post-deploy-job-4ldt7 0\/1 Completed 0 7d15h<\/span><\/em>
\npinniped-supervisor pinniped-post-deploy-job-m74gz 0\/1 Error 0 7d15h<\/span><\/em>
\ntkg-system kapp-controller-69c4d4bbb4-kwk5l 1\/1 Running 0 7d15h<\/span><\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

In order to simplify the authentication of Kubernetes clusters operating on different clouds, VMware has developed the Pinniped project accessible in Opensource. Pinniped has been integrated by default into the\u00a0VMware Tanzu Kubernetes Grid (TKG) offering since version 1.3, replacing the Gangway. inniped allows authentication from OIDC or LDAP sources. In the case of LDAP source,<\/p><\/div>\n

Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[401],"tags":[550,552,554,556,479,558,560,562,564,566,568,570],"post_mailing_queue_ids":[],"_links":{"self":[{"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/posts\/1111"}],"collection":[{"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1111"}],"version-history":[{"count":7,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/posts\/1111\/revisions"}],"predecessor-version":[{"id":1138,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/posts\/1111\/revisions\/1138"}],"wp:attachment":[{"href":"https:\/\/loeilduse.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1111"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1111"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1111"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}