# Write-only cluster / index? Auditing porpouse **URL:** \ **Category:** Elasticsearch\ **Created:** [May 8, 2016, 7:17pm UTC](https://discuss.elastic.co/t/write-only-cluster-index-auditing-porpouse/49494 "2016-05-08T19:17:44Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![sirkubax\_1](https://avatars.discourse-cdn.com/v4/letter/s/9de053/32.png) [@sirkubax\_1](https://discuss.elastic.co/u/sirkubax_1)\ **Post date:** [May 8, 2016, 7:17pm UTC](https://discuss.elastic.co/t/write-only-cluster-index-auditing-porpouse/49494/1 "2016-05-08T19:17:44Z")
Hi I have a goal of creating audit-prof solution, where **logs (indices) can not be modified nor deleted** (like write-only). The indices would have configurable TTL (like 365 days), and they would remove the date itself, but no user would be able to override, change, remove existing documents. For the moment I've created daily snapshots to "write-only" s3 bucket: > [@Snapshot to S3 - no delete permission](https://discuss.elastic.co/t/snapshot-to-s3-no-delete-permission/49493): > > I have a goal of creating 'write-once' snapshot of my current indexes. It would be a protection against someone 'accidentally' deleting some of the data. To achieve that I've created a S3 bucket, but I had to add IAM policy permission: "s3:DeleteObject", via [https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html) { "Statement": [ { "Action": [ "s3:ListBucket", "s3:GetBucketLocation", … It is close enough, but still - the last 24 hours (or the time since last snapshot), could be removed. In case of attack or some aware user action, someone have enough time to clean the ES cluster. Would You recommend better solution for 'persistent-secure' log storage? I may be missing some setting? ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [May 8, 2016, 8:59pm UTC](https://discuss.elastic.co/t/write-only-cluster-index-auditing-porpouse/49494/2 "2016-05-08T20:59:42Z")
You should secure your cluster like any other datastore/database. Have access control, have audit logging on that, take backups (as you are). ---
**Author:** ![sirkubax\_1](https://avatars.discourse-cdn.com/v4/letter/s/9de053/32.png) [@sirkubax\_1](https://discuss.elastic.co/u/sirkubax_1)\ **Post date:** [May 10, 2016, 8:31pm UTC](https://discuss.elastic.co/t/write-only-cluster-index-auditing-porpouse/49494/3 "2016-05-10T20:31:36Z")
Possible solution?: Ban the: XDELETE, URI: \*/\_update, But what about 'whole document update' where \_version number changes? Any way to disable 'in-place' document update'? ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [May 10, 2016, 8:58pm UTC](https://discuss.elastic.co/t/write-only-cluster-index-auditing-porpouse/49494/4 "2016-05-10T20:58:07Z")
Not unless you set the entire index to read only. ---
**Author:** ![sirkubax\_1](https://avatars.discourse-cdn.com/v4/letter/s/9de053/32.png) [@sirkubax\_1](https://discuss.elastic.co/u/sirkubax_1)\ **Post date:** [May 10, 2016, 9:01pm UTC](https://discuss.elastic.co/t/write-only-cluster-index-auditing-porpouse/49494/5 "2016-05-10T21:01:17Z")
Hm, tu continue the topic > > In Shield, you have different privileges, namely the create one which only gives the ability to create documents, but neither to update them nor to delete them. That's probably what you're looking for ---
**Author:** ![sirkubax\_1](https://avatars.discourse-cdn.com/v4/letter/s/9de053/32.png) [@sirkubax\_1](https://discuss.elastic.co/u/sirkubax_1)\ **Post date:** [May 11, 2016, 10:32pm UTC](https://discuss.elastic.co/t/write-only-cluster-index-auditing-porpouse/49494/6 "2016-05-11T22:32:29Z")
Actually I've been thinking wrt 'document in-place update' - since we can look for the documents with \_version \> 1 (that would indicate that they were modified), and additionally we can set the 'previous version gc delete' to a day index.gc\_deletes = 82800 we should be able to store the previous versions of documents, and/or at least, with a simple query, have a knowledge of the data modification (that is important too). What You think about that? ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [May 11, 2016, 10:44pm UTC](https://discuss.elastic.co/t/write-only-cluster-index-auditing-porpouse/49494/7 "2016-05-11T22:44:06Z")
I cannot find any recent reference to `gc_deletes`. I'd discourage use of it. ---
**Author:** ![sirkubax\_1](https://avatars.discourse-cdn.com/v4/letter/s/9de053/32.png) [@sirkubax\_1](https://discuss.elastic.co/u/sirkubax_1)\ **Post date:** [May 11, 2016, 10:45pm UTC](https://discuss.elastic.co/t/write-only-cluster-index-auditing-porpouse/49494/8 "2016-05-11T22:45:52Z")
> > **[Elasticsearch Versioning Support | Elastic](https://www.elastic.co/blog/elasticsearch-versioning-support)** > > Elasticsearch Versioning Support One of the key principles behind Elasticsearch is to allow you to make the most out of your data. Historically, search was a read-only enterprise where a search engine... ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [May 11, 2016, 10:52pm UTC](https://discuss.elastic.co/t/write-only-cluster-index-auditing-porpouse/49494/9 "2016-05-11T22:52:31Z")
Any **recent** reference; That blog post and SO link are both from 2013. There doesn't appear to be any such setting in 2.X. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 10:52pm UTC](https://discuss.elastic.co/t/write-only-cluster-index-auditing-porpouse/49494/10 "2017-07-05T22:52:22Z")