Accessing an accelerated table datamodel without access to the related index

[sylbaea]

Hello,

I am confused about delegation for accelerated data models.
I built an accelerated table data model, and granted access to users, and also granted access to any required knowledge object.

User can access the data model but it always return zero results.

I also see indexer log "WARN TsidxStats - User does not have access to any specified indexes"

But as soon as I grant access to the index used for this datamodel, it works fine.
One of the reason to use a datamodel here was to only expose a subset of data from this index. Is there a way to grant access to the datamodel without having access to the index ? I thought it was possible if the model is accelerated.

Regards.

[anm_mporter]

Datamodel acceleration doesn't work like report acceleration. No data is copied. Instead a pointer to the data in the index is created so all permissions apply to the index, not the datamodel.

If you want to show some fields and hide others it is tricky. You can play games with search filters on the role, but that is pretty fragile. If this is important you should clone the data into another sourcetype/index and redact the data you don't want to have certain users see. I think you can still use the same datamodel for both indexes, but you will get duplicate data.

See transforms.conf/CLONE_SOURCETYPE:

CLONE_SOURCETYPE = <string>
* This name is wrong; a transform with this setting actually clones and
  modifies events, and assigns the new events the specified sourcetype.
* If CLONE_SOURCETYPE is used as part of a transform, the transform will
  create a modified duplicate event, for all events that the transform is
  applied to via normal props.conf rules.
* Use this feature if you need to store both the original and a modified
  form of the data in your system, or if you want to send the original and a
  modified form to different outbound systems.
  * A typical example would be to retain sensitive information according to
    one policy and a version with the sensitive information removed
    according to another policy.  For example, some events may have data
    that you must retain for 30 days (such as personally identifying
    information) and only 30 days with restricted access, but you need that
    event retained without the sensitive data for a longer time with wider
    access.
* Specifically, for each event handled by this transform, a near-exact copy
  is made of the original event, and the transformation is applied to the
  copy.  The original event will continue along normal data processing
  unchanged.
* The <string> used for CLONE_SOURCETYPE selects the sourcetype that will be
  used for the duplicated events.
* The new sourcetype MUST differ from the the original sourcetype.  If the
  original sourcetype is the same as the target of the CLONE_SOURCETYPE,
  Splunk will make a best effort to log warnings to splunkd.log, but this
  setting will be silently ignored at runtime for such cases, causing the
  transform to be applied to the original event without cloning.
* The duplicated events will receive index-time transformations & sed
  commands all transforms which match its new host/source/sourcetype.
  * This means that props matching on host or source will incorrectly be
    applied a second time. (SPL-99120)
* Can only be used as part of of an otherwise-valid index-time transform.  For
  example REGEX is required, there must be a valid target (DEST_KEY or
  WRITE_META), etc as above.