In order to prevent too many automata constructions (which can be expensive) all the time, the automatas are now cached per action/privilege (since there are limited number of those, we don't expect a cache explosion).
Closeselastic/elasticsearch#125
Original commit: elastic/x-pack-elasticsearch@27a4e1fdbe
Shield needs to know about all the actions that are registered in core. We now check not only the external actions, meaning the classes that implement the Action interface, exposed via java api, but also all the transport handlers registered through the transport, which will contains all shard/node level actions plus the internal actions that are not exposed via java api.
We maintain two files, one for external actions, and one for the internal ones, and we check whether actions have been added or removed to/from core, to make sure we know about those changes.
Original commit: elastic/x-pack-elasticsearch@d6b68c44ee
Modified pom.xml to do static analysis without Jenkins
'mvn -DskipTests=true -Pstatic clean compile site' to start analysis
The reports are at target/site/project-reports.html.
Original commit: elastic/x-pack-elasticsearch@ddec28e8d0
Two reasons for this:
1) automatically convert the _all to its matching indices, in the context of the current user is authorized for, instead of resolving wildcards and then throwing authorization exception because the wildcard exp matches indices that the user is not authorized for
2) this makes the wildcards resolution secure, meaning that there is a single place that resolve wildcards. If it happened in shield while authorizing and in core while actually executing the operation, there would be mismatches which would allow to execute operation on indices that the user is not authorized for, if they get created with the "right" timing.
Closeselastic/elasticsearch#54Closeselastic/elasticsearch#105
Original commit: elastic/x-pack-elasticsearch@a02c6fbccf
esvm is small commandline tool to start different cluster in a fast way.
This commit adds a preconfigured .esvmrc for starting a SSL enabled cluster
in no time.
All you need to do is to build the package and run
esvm shield
This starts a two node cluster with SSL enabled on HTTP and transport
Original commit: elastic/x-pack-elasticsearch@f701fd1134
If a user was created, but the user was not supplied roles on the commandline,
a bogus 'user:' was added to the roles file. This fix checks, if roles were
supplied when creating a user and only changes the roles file in that case.
Original commit: elastic/x-pack-elasticsearch@286951c016
In order to prevent confusion when starting up nodes (so they can join easily together)
and adding some usability connections are not denied by default on the server side.
Original commit: elastic/x-pack-elasticsearch@6ffe3a7df2
SSLConfig is split into SSLConfig and SSLTrustConfig.
OpenLdapTests and ActiveDirectory tests connect via TLS to EC2 instances.
Original commit: elastic/x-pack-elasticsearch@ea38e58dea
The authc service will now authenticate the user on the rest layer as well, meaning there will only be a single authentication process no matter what is then entry point to ES (for example, if a rest handler executes two internal requests... like some of the _cat APIs, there'll still be a single authentication process)
In addition, the audit logs will now log REST authentication failures such that the remote address and the rest endpoint will show up in the logs as well.
Original commit: elastic/x-pack-elasticsearch@07af440147
Areek Zillur
uboness
javanna
Karel Minarik
c-a-m
Bill Hwang
Alexander Reelsen
Paul Echeverri
Michael McCandless