elasticsearch 🚀 - Support for proxied PKI authentication

Pinging @elastic/es-security

elasticmachine on 11 Oct 2018

Some of the material here might be of interest: https://docs.google.com/presentation/d/1ko8xveyspZsZ6RWcXwHizPnt3R1EAGFdV__a2ZTGUDM/edit?usp=sharing

alexbrasetvik on 18 Oct 2018

🎉1 👍1

The client connection proxying the certificate must be authenticated using PKI

Do we specifically mean that it must use the PKI realm, or simply that it must have a validated client certificate?

tvernum on 25 Mar 2019

Do we specifically mean that it must use the PKI realm, or simply that it must have a validated client certificate?

My initial thought was that we should require the connection to be authenticated with the PKI Realm and the proxied client certificate should be authenticated with the PKI realm as well. Upon further thought, I do not feel that aspect is a hard requirement. I think the following should be properties that we keep though:

the connection from the proxying app has authentication
the authenticated user from the proxying app needs to be authorized to proxy the certificate

jaymode on 25 Mar 2019

The description above is of a variant of run-as functionality; there is one authenticated client (kibana) that authorizes as another principal. We already have the privilege model to define which principals can authorize as which one (the run_as privilege). The way to convey the authorization principal is through the es-security-runas-user HTTP header.
Therefore, one option is to extend the existing run_as functionality to make it work in the case that the authorization principal is defined by a X509v3 certificate. There are de-facto standards to convey the client certificate (or fields of it) from the proxy (kibana) to the service provider (elasticsearch); eg the X-SSL-CERT family of headers of nginx.

Implementation hurdles:

there are possibly multiple identities bound to the certificate; we need to build capabilities into ES that allow the administrator to define THE way to parse out the principal.
if we wish to allow extracting the principal in terms of the client's trusted certificate chain it will become very complex; not least because passing cert chains using the de-facto headers is not available.

Qualms:

Kibana is more than a proxy doing authentication as part of the TLS termination. Kibana does many more requests to ES for a single incoming request; there is also the notion of background jobs running as the user. Therefore we would be stretching the X-SSL-CERT outside the de-facto use case (there is no inherent security problem with that, but if we go with a standard practice let's follow the use case the practice is used for, otherwise find another standard).

Note that this alternative will not add or extend any authentication realm, it will extend an authorization feature (the run_as impersonation).

Another alternative is to create a new API that implements the delegation functionality of the PKI realm. In ES we broadly have two types of realms, the ones that validate secrets, such as passwords, and realms that consume authentication statements from third party services (SAML, OIDC, Kerberos). The latter do not do authentication but validate an authentication statement (claims, tickets). Upon successful validation, ES issues a token usable by kibana to authorize as the user in the claims/ticket.

In this proposal ES will be validating the certificate chain of the client that connected over TLS to kibana and afterwards will emit a token to be used by kibana to authorize as the user. Kibana then stores the token on the client as a cookie, and forwards it to ES as a header.

Implementation hurdles:

The same problem with extracting a principal from a certificate chain on the ES side.
Kibana has to make sure the token in the cookie is associated with the current TLS client certificate; The underlying TLS connection can change without a proper logout ceremony. Kibana has to detect that the token in the cookie was issue for a different client certificate than the currently used one (after a new TLS handshake) and re-request a new token.

Qualms:

Certificate chains may look like signed assertions of identity, but they lack the crucial short time validity. Without a limited lifetime, the cert chain used as an identity assertion provides little guarantees. Therefore, this is not a true realm, offering a false sense of security (unusable outside Kibbana) and relying on Kibana to validate the association of the secret private key with the certificate (during TLS termination).

Another alternative is to completely delegate authentication to Kibana, including parsing of the principal. This is a variant of the first alternative. In this way there is little to do on the ES side, but do the role-mapping to the principal (basically run-as with the option to not lookup the user). The principal can be conveyed to ES via headers (X-SSL-CERT friends) or fancy JWT tokens. Both of these require TLS between Kibana and ES. The only narrow advantage of JWT is the ability to communicate more complex attributes about the user that can be utilized in role mappings.

RFC @elastic/es-security @elastic/kibana-security

albertzaharovits on 3 Jun 2019

When discussing options, I propose we argue about what the considered option is bringing over simply using the existing run-as ES feature.

I will shortly describe the setup with run-as, and let us consider this as the baseline implementation.

Kibana does TLS termination and parses the principal out of the DN in the Subject attribute of the client's certificate and then forwards that principal value in the es-security-runas-user header to ES.
Kibana has to make sure that the header value of every request to ES reflects truthfully the client cert on the TLS session between the client and Kibana. Similarly to ES's PKI realm, Kibana should permit the configuration of additional truststores that must validate the client cert, in addition to the HTTP layer validation. There ought to be mandatory TLS between Kibana and ES. ES is not aware that Kibana validates PKI certs (eg in audit logs) but can do the LDAP lookup of the principal by rebuilding the DN with the rules of the individual LDAP realms. ES also has to be configured to permit run_as for the Kibana principal

I believe this satisfies most of the requirements, and I would suggest we go with this. Alternatively, let us find compelling use cases not satisfied by this setup to motivate implementation variations suggested in https://github.com/elastic/elasticsearch/issues/34396#issuecomment-498216685.

albertzaharovits on 3 Jun 2019

Previous discussion about allowing Kibana to utilize the run-as header have ended with us deciding that we shouldn't grant this privilege to the kibana_system role because of the security ramifications. If I understand correctly, the other solutions which have been proposed don't require the relaxing of this consideration, and prevent Kibana from being able to "run as" arbitrary users.

kobelb on 3 Jun 2019

It does not have to be the kibana_system the principal that run_as; it could be some dedicated user that is configured on ES to run_as as a defined set of users. The username and the ES privilege could be made part of the configuration procedure.

But, in essence, the issue remains: We have to trust Kibana with forwarding the identity of the client, because the client cannot offer ES any proofs. We trust that Kibana keeps its keypair for TLS to ES a secret.

albertzaharovits on 3 Jun 2019

A few comments for now to hopefully help the discussion forward, I'm not sure I've reached a conclusion yet as to what I prefer from the given options:

there are possibly multiple identities bound to the certificate; we need to build capabilities into ES that allow the administrator to define THE way to parse out the principal.

Can you elaborate ? Client certificates will have 1 subject. I get the point about parsing (CN/DNs/emails) but not the multiple identities one.

It does not have to be the kibana_system the principal that run_as; it could be some dedicated user

The actual threat would remain though. Someone with access to Kibana (and thus to this user's credentials) will be allowed to run_as arbitrary users.

that is configured on ES to run_as as a defined set of users

This is tricky. Wouldn't that mean that setting up PKI in Kibana would require you to know up front all your users that might authenticate with a client certificate/key and pre-configure ES to allow the service user with run_as as any of these?

We trust that Kibana keeps its keypair for TLS to ES a secret.

Do you mean that we should require TLS mutual authentication from Kibana to ES ? What would the benefit be for this to be a strict requirement ? Or could the same be said for kibana/service user credentials ?

But, in essence, the issue remains: We have to trust Kibana with forwarding the identity of the client, because the client cannot offer ES any proofs.

The difference is that in the run_as with es-security-runas-user approach, if that trust is breached, then a malicious user can impersonate any ES native user.

If, alternatively, we have Kibana only validate that the user who authenticated has access to the private key that corresponds to this certificate, and ES verify the certificate based on its configuration, a malicious user with access to Kibana would also need to forge a certificate from a CA that ES trusts ( as ES will still validate the certificate signature ) or steal the client certificate from a user. Given that client certificates are not meant to be secret, this is not a huge mitigation factor, but people don't usually publish their client certs.

Certificate chains may look like signed assertions of identity, but they lack the crucial short time validity. Without a limited lifetime, the cert chain used as an identity assertion provides little guarantees. Therefore, this is not a true realm, offering a false sense of security

I'm not sure I agree with this. The lack of short time validity is potentially missing from all client certificates - not relavant to this implementation aspect only - and, still, these are widely used for authentication. There are even PKI setups/deployments that issue short lived certificates on demand when they are used for client authentication.

jkakavas on 4 Jun 2019

Thanks @albertzaharovits, that's a very clear write up.

Disclosure: I still prefer the option _to create a new API that implements the delegation functionality of the PKI realm_, but I'm open to changing my mind.

there are possibly multiple identities bound to the certificate; we need to build capabilities into ES that allow the administrator to define THE way to parse out the principal

The same problem with extracting a principal from a certificate chain on the ES side.

We already have a way to do this in PKI realms (a regex on the DN). It's simple, but has not (so far) been an issue.
For me this is an argument in favour of a _delegated PKI realm_. If we want to improve our certificate-to-user implementation then we just do it in the PKI realm and it would be available for both Kibana and ES terminated TLS. I don't think we want to have multiple ways to solve the same underlying problem of extracting an ES-capable user identity from a certificate.

Note that this alternative will not add or extend any authentication realm

This for me is actually a negative (but it is a design choice that we could change).
Identity & Authentication in Elasticsearch is based on realms. Here we have a pseudo-authentication mechanism (pseudo in that it doesn't happen within Elasticsearch itself, but it does take place within the Elastic Stack) that doesn't use realms. I don't like the idea of having something that's _different_ when it doesn't need to be.
And, in order for run-as to work the user has to exist in some realm. So this propsal _requires_ that some sort of realm exist for the users that authenticate in this way. It might be native or LDAP, but it would not support _ephemeral_ users (with role mapping) in the way Elasticsearch PKI does - unless we took the 3rd option you propose.

Kibana has to make sure the token in the cookie is associated with the current TLS client certificate

This is a good point, but is true in any of the alternatives. Kibana stores identity information in the sid cookie. And surprising, broken things will happen if the information in sid falls out of sync with the TLS client cert. I would propose putting a cryptographic hash of the cert into the cookie and, on each request, validate that it the cookie value still matches the TLS value.

Even in the run_as approach, it might be possible to ensure that the connection to ES always reflect the client certificate, but that would not protect Kibana feature controls (menu options, etc). No matter what solution we come up with, Kibana will need to detect client-cert changes and force a logout-login cycle.

Certificate chains may look like signed assertions of identity, but they lack the crucial short time validity.

Since (per @jkakavas's commen above) this is fundamentally true of certificates, I assume your concern is that we don't know _when_ Kibana performed the TLS handshake and we might be subject to replay attacks. If this is something we are particularly concerned about then we can add the necessary information into the API. The body of the "swap this certificate for a token" API could include a timestamp & a signature of some sort.
I don't know that the risk is sufficient to require that (I'd need to think some more) but it's not an unsolvable problem.

Similarly to ES's PKI realm, Kibana should permit the configuration of additional truststores that must validate the client cert, in addition to the HTTP layer validation.

This seems like a downside for this option. It would require that Kibana duplicate functionality that Elasticsearch already has.
Under option 1, Kibana must replicate all the trust options that ES has, or else Kibana PKI would be (feature wise) an inferior offering to Elasticsearch PKI. Under the 2nd option, Kibana just needs to have enough configuration to perform a handshake. That could just be the corporate root CA, and Elasticsearch can perform additional trust checks (which could include doing different role mapping, or lookup in a different LDAP directory) depending on which CA signed the client cert.

ES also has to be configured to permit run_as for the Kibana principal

In the simplest case of using the existing es-security-runas-user header for this, it effectively grants Kibana superuser privileges.
Kibana would be able to run-as elastic because run-as doesn't have restrictions on the realm or the roles that the target user has.
We _could_ build additional controls into run-as to solve this (I would lean towards "run as any user from realm X/Y/Z"), but that is additional engineering work, and we would have to work out how you configure it. The kibana_system role is fixed, so we'd need to have some mechanism by which you could specify which realms were permitted when the kibana principal tried to run-as.
This would bring run-as more in line with authorization_realm (which specify which realms to use for lookups).

An alternative is to take the other approach of putting the whole cert into the header. At least then it is only possible for Kibana to run-as a user that can be looked up by certificate (but then this is tying the implementation to a PKI realm which it sound like you want to avoid).

We have to trust Kibana with forwarding the identity of the client, because the client cannot offer ES any proofs

I think the "trust Kibana" terminology is proving to be too vague. It doesn't explicitly describe the risks we're trying to mitigate, and so it leads to all options appearing to be the same "we have to trust Kibana" even though they have different risk profiles.

The main issue that I think we should be identifying and controlling for is if an attacker manages to extract the kibana username+password from Kibana (e.g. through an RCE) and then uses that to do a privilege escalation on Elasticsearch.
If kibana has the ability to run_as _any_ user then this escalation is trivial - you just send es-security-runas-user: elastic. So how would we protect this? One option that you allude to is to enforce TLS from Kibana to Elasticsearch, yet that only provides any real protection if we are using Kibana's client cert as its proof of identity. TLS by itself doesn't do much there, and even requiring a client cert might not (depending on the trust anchors), it has to be locked down to a specific keypair.

It is possible to do that. It would require that we don't put any username/password into kibana.yml, ideally disable the kibana user and then map the Kibana cert's DN to the kibana_system role. But, then we've switched the secret that the RCE needs to extract from being the Kibana username+password to being the Kibana cert+key. That's better, but it still means Kibana has a secret that end up being the keys-to-the-kingdom, and the right RCE will get you there.

What I'd like for us to have is some sort of protection that the stack admin can enable that would limit the set of users/roles that Kibana can escalate too.
Linking Kibana PKI to an ES realm provides an option for that. If the proxy_pki token grant has been configured against a proxy_pki realm, then that realm can be configured to never grant superuser (right now that means, don't create a role mapping for superuser, but we could look at putting something more explicit in if needed). While we cannot (and would not) enforce that ourselves, it does mean that the stack admin can manage this risk themselves.

There are other options that would be useful for any of the alternatives. For example IP restrictions on some part of this (e.g. the kibana user) so that the kibana credentials are not useful outside of the machine(s) on which Kibana runs.

Outstanding Issue
We still don't know _how_ people expect to map these certificates to a user-with-roles in ES/Kibana. But for me that's an argument for aligning this with PKI realms because:

We have something that works already and people seem OK with it.
It has (slightly) more than the minimum feature set. We support role-mapping by username and/or DN, and we support LDAP/native user lookup through authorization_realms.
Hooking into the realm infrastructure means that any new features we build there are automatically (or _mostly automatically_) available to Kibana PKI (e.g. when we added authorization_realms). This would include possible future development like considering additional data within the certificate chain (as mentioned in your earlier comment), extracting additional metadata from certificates (for role mapping) or having a mapping-function for PKI-principal to LDAP-principal (for authorization_realms).

tvernum on 5 Jun 2019

Thanks @tvernum and @jkakavas for the valuable feedback! There is a lot to unpack, so rather than individually answering each question and suggestion I will try to elaborate on the proposals.

Generally, I think we (me, Tim and Ioannis) are all OK with extending the PKI realm to delegate authentication inside the Stack by having Kibana pass the client cert from the TLS handshake to ES in exchange for a token, i.e. Tim's original proposal, i.e. second alternative from https://github.com/elastic/elasticsearch/issues/34396#issuecomment-498216685.

I also believe that given TIm's argument in

Kibana stores identity information in the sid cookie. And surprising, broken things will happen if the information in sid falls out of sync with the TLS client cert. I would propose putting a cryptographic hash of the cert into the cookie and, on each request, validate that it the cookie value still matches the TLS value.

and given that the Kibana server is more than a proxy (crafts ES requests, background jobs, etc) we can dismiss my argument that hoisting session information from the transport layer to the application layer is not required unless we go with the currently favored approach (ie it is required anyway).

Moreover, I also agree with

I think the "trust Kibana" terminology is proving to be too vague. It doesn't explicitly describe the risks we're trying to mitigate, and so it leads to all options appearing to be the same "we have to trust Kibana" even though they have different risk profiles.

and I believe we can all surmise that a trusted cert chain is more difficult to craft (or snoop from a compromised Kibana server) than a substring from its Subject field (ie the run-as principal) which would probably be scattered everywhere in the Kibana's memory since it has to go with every request to ES.

What I still don't like is that, for a lack of a better word, we "fake" the delegation and try to cover for it by saying it is "inside the Stack" and if we have to, we can jump in and do a threat analysis. Inside ES, all the other realms that delegate authentications (SAML, OIDC, Kerberos) accept timestamped signed assertions. Upon successful validation they release a token. Client certificates are signed identity assertions but are not time bound. This is crucial. My argument is that toggling the delegated authn on a PKI realm, as proposed herein, would be akin to disabling the timestamp validation on the SAML realm or the OIDC realm. We can put controls in place to compensate for that (TIm's IP firewall proposal) and narrow the pool of users, which leans me to OK this proposal, but this is a genuine conceptual problem with practical fixes.
The other proposals (run-as types), although inferior from the Stack perspective, acknowledges this weakness and passes the responsibility to the Kibana server to do the authentication. I think we discussed the technical problems of these alternatives (consistency with ES's PKI realm, Kibana is more exposed, passing cert chains in headers, ...) and I agree the run-as type of solution is impractical. But at least it does not have the conceptual weakness.

I wish to propose a variant of the favored approach, that I believe makes true the delegation concept. Let us make Kibana construct a JWT type of JSON, that contains the client certificate chain from the TLS session, a timestamp and a signature with a shared secret (could be the kibana_system user's password, or a dedicated secret between Kibana and ES) and let it exchange that for a token. We could probably standardize this as a JWT (it is pretty lax) but we don't really have to. What it is important is that a standalone ES server does not delegate authentication without validating signed timestamped assertions. Maybe an attacker that can capture a client certificate and the kibana_system password also has the capability to discover the signing secret and craft the JWT, so there is no practical improvement, but ES taken separately handles delegation by the books. I feel strongly about this, what do others think?

albertzaharovits on 16 Jun 2019

Inside ES, all the other realms that delegate authentications (SAML, OIDC, Kerberos) accept timestamped signed assertions ... Client certificates are signed identity assertions but are not time bound ... toggling the delegated authn on a PKI realm, as proposed herein, would be akin to disabling the timestamp validation on the SAML realm or the OIDC realm.

I think this mixing different concepts.

SAML assertions are typically sent via an intermediary, thus they are inherently subject to replay attacks. The design of a SAML assertion is intended to counter this risk by including time constraints that make the assertion fail if replayed at a later date, but the primary need for this is because the assertion may travel via an untrusted channel (e.g. the user's browser).

If we have a direct back channel to the authentication server (AS), then a timestramp would be technically unnecessary, as we could pass a session token to the AS and enquire whether the session is still valid. That would mitigate the same "hold and replay" attack without using a timestamp in the message (at the cost of being more chatty and having a runtime dependency on the AS).

Similarly if we obtain a message directly from the AS and we are confident in its integrity then signing is unnessary. SAML recognises this in making signatures mandatory for the Web profile (HTTP-POST/Redirect) but accepting that these are unneccessary when the IdP and SP are communicating on a transport that has end-to-end protection.
Signing allows us to know the a message originated from a particular party even though it has passed through untrusted intermediaries.

So, if the kibana server is communicating directly with ES, over an authenticated TLS connection, then I don't see why we _need_ signatures or timestamps.

The fact that the message was sent _now_ is sufficient timestamp to know that the certificate is valid for a current session.
The fact that the kibana user authenticated is sufficient evidence that it originated from kibana
The TLS connection provide message integrity and prevents tampering.

I'm not in any way opposed to having a signed & timestamped protocol, but I just don't see what risk it is mitigating that isn't already covered by a direct connection with TLS + authc.

Timestamps are easy enough. If we have a reason to need one, then we can implement one. But we also need to think about clock skew, so it's not a trivial case of having Kibana set an expiry 60 seconds into the future.

If we need signing, then I'd like to consier why TLS client auth is not the correct solution for it. That will provide signatures at the transport layer and we can enforce either a pre-shared key (certificate pinning) or the more typical issuer (CA) checks. Technically, of course, requests sent over TLS are already signed using a session key, but if we think we need something more than that, then I would hope that client certificates would be sufficient for that.

tvernum on 17 Jun 2019

That said, I think we're at the point where we can and should get into some implementataion.
I think the only current points of contention are:

what metadata (timestamp) Kibana would need to send alonside the certificate chain
whether that payload requires a signature
what additional validation we would perform on
- the payload (metadata)
- signature (if any)
- connection (does it require client certificates)

We can start building the basics without having answered those questions.
To start with we'd need:

[ ] A proxy written in Java that implements what we expect of Kibana (for integ testing)
[ ] An endpoint of some sort for that to call (either a new token grant_type, or a whole new endpoint)
[ ] The actual authc against PKI realms & exchange for the token
[ ] Some sort of controls to enable/disable this feature for some/all realms and some calling user/role (e.g. kibana_system). I don't think we've decided what this would look like, but I'm pretty sure we do not want to ship it as "always on", given how it changes the trust model between Kibana & ES

If we have available engineering cycles (and I think we do), then let's get on with what we do know and see how we go.

tvernum on 17 Jun 2019

I totally agree with Tim's comments on https://github.com/elastic/elasticsearch/issues/34396#issuecomment-502573636.

I don't see what structuring the message from Kibana to ES in a JWT and signing this JWT buys us. Requiring authentication ( kibana - or another user with required privileges - user credentials ) on top of TLS offers the same guarantees with no need for additional implementation.

Client certificates are signed identity assertions but are not time bound. This is crucial.

I still can't see what is the issue with the time validity of the client certificate in this specific case. Could you please explain the threat you see and why you consider this such high risk / or why it is not mitigated by tls and authentication ?

jkakavas on 1 Jul 2019

I totally agree with Tim's comments on #34396 (comment).

I also agree with Tim.

I still can't see what is the issue with the time validity of the client certificate in this specific case.
Could you please explain the threat you see and why you consider this such high risk / or why it is not mitigated by tls and authentication ?

A certificate chain is an assertion of identity and has a time validity. SAML and OIDC identity assertions also have time validities, but those are much more restricted compared to certificates. My observation was that in the PKI delegation flow we are using certificates more as SAML and OIDC assertions. Although the twist, which Tim pointed out, is that signatures are not _required_ (but also not forbidden) in SAML for backchannel communications.

Everything on top of TLS and authentication has confidentiality, authentication (mutual?), integrity and replay protections. There is nothing more needed.

But I would also want us to consider ES outside of the Kibana context. There is a PKI realm installed on ES which allows delegation (which is implemented as we all seem to agree). Basic credentials over TLS are crack-able, the way a pure PKI realm is not. So a PKI realm which supports delegation is more exposed. How do we limit that? Tim mentioned some alternatives, all good ones.

But one alternative is also signing the "assertion" with another secret besides the kibana_system password. This secret has another scope than that password, so it could have a larger length/entropy, is not stored in the .security index, cannot be changed by the API, could be different for different nodes, could be different for different realms, does not complicate the Kibana setup in the way mutual TLS would...

albertzaharovits on 2 Jul 2019

We discussed one way of mitigating leaked Kibana credentials using out of band authentication after the TLS mutual authentication between Kibana and Client. In case the Kibana credentials were leaked, those could be used with any user's public certificate and use them to exchange token with ES. In case of out of band authentication, ES will communicate OTP to the client via some channel (for ex. extract email address from the certificate and then send OTP via email just one way to do this) which the client will need to use to create assertion stating Kibana is allowed to act on its behalf.

We have decided not to do this for the following reasons:-

complicates the UX for the login scenario
in some environments, the other channel may not be available

bizybot on 8 Jul 2019

TL;DR I reckon we do NOT need any restricted authn schemes for the proxying subject, for the delegate-PKI feature. But we need to investigate further authz options as part of our permission model refactoring in #44048. But this is not critically important for this feature.

Citing Jay from https://github.com/elastic/elasticsearch/issues/34396#issuecomment-476332090 with

I think the following should be properties that we keep though:

the connection from the proxying app has authentication

the authenticated user from the proxying app needs to be authorized to proxy the certificate

I think we need to start discussing the authentication and authorization aspect of the PKI delegation feature. This also ties in with Tim's

Some sort of controls to enable/disable this feature for some/all realms and some calling user/role (e.g. kibana_system). I don't think we've decided what this would look like, but I'm pretty sure we do not want to ship it as "always on", given how it changes the trust model between Kibana & ES

from https://github.com/elastic/elasticsearch/issues/34396#issuecomment-502577583 .

On the authentication side I believe we have to make a decision whether we feel the need to enforce any authentication scheme (the prominent option being client authn TLS) and restrict the BASIC method (which kibana_system normally uses). The rationale for this is that some schemes are more secure than others (eg. the kibana_system password can be brute forced, but a private key cannot). TLS with client authn is presumably the prominent option because, in this case, there is definitely a PKI realm configured on ES so this strong authn scheme does entail lesser configuration burdens (on the ES server at least). But this is not generally true because there are policies around certificate handling, and this does not even consider the configuration burden for the proxying app which could be load balanced. Also for the authentication aspect, I had previously been peddling a form of HMAC at the application logic level. It is also a form of authentication because it implies a shared secret between ES and the proxying app. But it is a form of authentication at the "feature-level" because it does not use the authn framework in ES Security, and it would have to happen after that one (given the request processing order). There are a few benefits, all originating because the scope of the secret is at the feature level. For example, if the secret is a new realm secret setting, then realms and nodes can have different values for it allowing finer grained control over the proxying identity. Moreover it does not encumber the kibana_system with more privileges, and it allows for different password/secret policies (the PKI delegation secret cannot be changed by the password API). However, all these benefits exist only when specifically comparing to kibana_system. But in the general case, this form of "feature-level" authentication is redundant. For example, there could be a separate file-based user that the proxying app uses solely for this feature, and this would have all the advantages as any other authn layer at the "feature-level".

Overall, I do not think we need any specific forms of restricted authentication for the PKI delegation feature. This is because, and this refers to the next point, the es-admin can create role-mapping rules such as only certain users will be authorized to use this feature. And the es-admin has all the capacity to tune the authentication strength. Given the previous examples, the privileges could be granted only to a certain delegate-pki user which is part of some PKI or file-based realm. Moreover, if we are concerned about over encumbering kibana_system with privileges, we should recommend a different system user for this feature on the Kibana's side.

In terms of authorization the more fine grained the better. Hence _the best_ is a way for the es-admin to be able to grant the "delegate-pki" privilege to some specific principals such that they can "delegate-authenticate" as some specific principals. Given that https://github.com/elastic/elasticsearch/pull/44106 introduces a new transport action, and using the usual role mapping rules, it is easy for the es-admin to restrict the principal doing the delegation (the proxying app), but it is not possible, given the current state of the authorization framework, to define permissions that restrict the "delegated-authenticated" user. We could "bake" this part of the authorization at the realm level. In this case there would be a PKI realm setting namespaces, used to define these permissions (who can authenticate as who, in the case of this realm, using the delegation feature). This is ugly from the es-admin pov because it splits authorization configuration in two places, and it is kludgy from an engineering perspective because it mixes authorization with application logic. We might also improve our permission model to work outside the request "boundary", such as allowing to authorize and inspect on the response as well. I think it would be wonderful if we can achieve something like that as part of the effort in https://github.com/elastic/elasticsearch/issues/44048 . My stance is that we can ship this feature without a complete authz scheme, without allowing to specify the "authenticated-as" principals in the permission model. But work on this item separately, as a follow-up, after we settled on https://github.com/elastic/elasticsearch/issues/44048 .

albertzaharovits on 10 Jul 2019

We have discussed the matter of restricting the delegation feature in our weekly team meeting.

There would be a cluster privilege granting the authentication delegatee user (ie kibana_system) the ability to get access tokens for any user that the PKI realms normally authenticate. This privilege will most likely stand on its own, not be included with the others apart from all.
For the es-admin to restrict the users that can be authenticated by the delegatee, there would be user metadata fields populated exclusively when authn has been performed in this way, so that role mapping rules can differentiate such users. Hence, role mapping rules can exclude particular users to be authenticated by the proxy by not mapping any roles to them.

albertzaharovits on 18 Jul 2019

👍1

Hi, I’d like to contribute some thoughts on this.

Is the suggestion here that there would be a master certificate that connects to ElasticSearch via the TPS handshake? If so is there a requirement for that master certificate to be authenticated via the pki realm?
Can we authenticate via another realm? Then the TLS handshake incorporates the certificate for the client connecting to Kiran’s.

Thanks

ShazCho on 23 Jul 2019

Specifically I meant to mention the master account being authenticated via Kerberos then TLS used for certificate pki authentication during the proxy engagement.

ShazCho on 23 Jul 2019

Hi @ShazCho,

Yes, in the current proposal, the proxy user doing the delegation can be authenticated by "any" realm, Kerberos included, not only PKI ("any" is quoted because some realms require browser interaction (SAML, OIDC), whereas the user doing the delegation works as a _system user_, therefore the scheme to achieve delegation in those cases is probably wrong).

albertzaharovits on 23 Jul 2019

Ahh thanks. So I’ve been waiting for Kibana PKI for a while however the system_user from my perspective needs to be approved by a variety of different mechanisms depending on each implementation I do eg pki, Kerberos, saml, oauth. Does this mean that system_user can only be authenticated via pki?

ShazCho on 23 Jul 2019

Elasticsearch: Support for proxied PKI authentication

Most helpful comment

All 22 comments

Related issues