Hi, this is more of a feature request.
When evaluating Shield in a setup that's already being used, it would be extremely helpful to be able to disable it, but still see what would be blocked if it was enabled. Like the permissive policy in Selinux does. As it is now, I expect trouble when we install Shield live. I'm aware that I ought to have a complete test setup, but I don't. Is there anybody out there with similar thoughts?
Hi Suny,
This is an interesting feature request and I see how it could be useful. Would you expect that users are still required to authenticate but the authorization aspect is where it would be permissive (ie allow everything)?
Thinking out loud a little bit, you could achieve something similar by enabling audit logging and using admin privileges at first. You could then examine the access_granted entries to see what permissions you would need for each user.
Jay
@Suny Re-reading the question makes me think that using anonymous access with admin privileges and auditing would be more in line with what you are looking for. Do you think that would work for you?
Hi @jaymode,
thanks for your reply, and for thinking this could be useful.
The answer depends on how big the mess is you're in. Imagine you have a historically grown elasticsearch cluster - those things exist now. And you don't really know who's writing and who's reading, and you want to regain control, but you know people will kill you if things stop working for them. In this situation, you wouldn't want authentication, you want the cluster to keep accepting and processing everything as it did before.
And in this case, admin privileges or anonymous access wouldn't help.
For the record, this is not what's happening to me. My cluster and my users are much nicer, but I'm much more lazy. I'd like to evaluate Shield on production without having to upgrade logstash and our plugins.
Hi @Suny,
Can you expand on why anonymous access with admin privileges and audit logging wouldn't help?
You're right, that works for me. Thanks a lot.