Skip to content

[RORDEV-2145] PKI authentication example - #8

Open
coutoPL wants to merge 8 commits into
masterfrom
feature/RORDEV-2145
Open

[RORDEV-2145] PKI authentication example#8
coutoPL wants to merge 8 commits into
masterfrom
feature/RORDEV-2145

Conversation

@coutoPL

@coutoPL coutoPL commented Aug 7, 2026

Copy link
Copy Markdown
Collaborator

A runnable example of certificate-based authentication, for customers to try before the feature ships.

Three certificates from one CA: two services that authenticate and get different permissions, and a human certificate that is refused because it sits outside the provider's subject_dn_base. A password user shares the same port, and Kibana logs in with it.

The plugin is not released yet, so the zip is committed under runner/plugins/.

curl -sL https://raw.githubusercontent.com/beshu-tech/readonlyrest-examples/master/quickstart.sh | bash -s pki-auth --branch feature/RORDEV-2145

Elasticsearch and Kibana 9.5.0. Verified end to end.

coutoPL added 8 commits August 6, 2026 20:45
Three services authenticate with nothing but a TLS client certificate, and a password
user shares the same port to show the two coexist.

The certificates carry the demonstration. svc-logstash and svc-dashboard differ only in
the OU naming their role, so one may write logs-* and the other only read it. jsmith is
the case worth having: the node trusts that certificate, it chains to the same CA and it
even carries the ingest role, and it is still refused because it was issued into the
People branch rather than Services. One corporate CA nearly always issues to more than
one population, and without subject_dn_base a CN extractor authenticates humans as
services.

Client authentication is optional rather than required, so a caller with no certificate
still reaches the ACL and falls through to the password block; required would reject it
during the handshake and the analyst would never get in.

PKI is not in a released plugin yet, so the example runs a locally built one and says so.
There is no Kibana: certificates are for machine-to-machine traffic, and curl is the
client.
Kibana earns its place by being the counter-example: a browser presents no client
certificate, so Kibana authenticates with a password on the very same port the services
use certificates on. That is mixed mode doing its job, and it is also the limit of the
feature - anything reaching Elasticsearch through Kibana arrives as Kibana's service
account, so people still need a password or SSO path.

The Elasticsearch plugin is built locally while the Kibana plugin is downloaded, so
their ReadonlyREST versions can drift; both .env and the README say what to do if they
do not line up.
…for a build

ROR_ES_FILE is a Docker COPY source, so it has to be relative to the build context -
an absolute path could never have worked, whatever was built. The zip now lives in
runner/plugins/ and the example runs with ./run.sh alone.

Pinned to ES 9.5.0, which is what the PKI integration suites actually ran against; the
example previously named 9.4.4, a version nothing had been verified on. es94x covers
both, but there is no reason to ship the untested one.

Running it showed the Kibana plugin version was wrong too: 1.69.1 does not exist for
Kibana 9.5.0 and the image build failed outright. 1.70.3 is the released version that
covers it. Elasticsearch still runs the local pre-release, so the two differ by design.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant