Understanding Subscription Policies in Immuta

This documentation provides strategic guidance and best practices for leveraging Immuta's capabilities to their fullest potential. Please note that this content is for informational purposes only and may include forward-looking statements. Always consult with your Immuta representative for specific implementation details and personalized advice.

Introduction

In Immuta, subscription policies are an essential mechanism for controlling access to data tables and views. These policies determine whether a user can access a data object at all, acting as a gatekeeper before any other policies are applied. This guide explains how subscription policies work, how they differ from data policies, and the common patterns for implementing subscription controls.

What Are Subscription Policies?

Subscription policies in Immuta govern whether users are granted access to specific tables or views. These policies are distinct from data policies, which control what users can see and do with the data once they have access.

  • Subscription Policy: Controls on/off access to a table or view. It determines whether a user can see and query a data object.

  • Data Policy: Governs what data users can see and interact with once they have access. This can include column masking, row-level filtering, and cell-level masking.

By combining subscription and data policies, Immuta ensures that users only access the right data and that sensitive information is protected based on real-time user attributes and data conditions.

Common Patterns for Implementing Subscription Policies

There are several common approaches to applying subscription policies in Immuta, each suited to different organizational needs.

Birthright Table Access

This pattern is based on user attributes, such as their department or role, which are typically pulled from an identity platform. Users automatically gain or lose access to tables based on their attributes. For example, if a user moves to a new department, their access to certain tables is revoked, while access to new tables is granted.

Key features of birthright access:

  • Access is driven by user attributes or group memberships.

  • Users are automatically subscribed or unsubscribed from tables as their profile information changes.

  • Ideal for organizations that want access to be tied to job roles or other organizational facts.

Data Mesh / Domain-Based Access

In this approach, subscription policies are decentralized to allow domain owners or data stewards to manage access controls. This model is especially useful for organizations adopting a data-as-a-product mindset or implementing a data mesh architecture. Each domain is responsible for defining who has access to their data, ensuring that users closest to the data can manage permissions effectively.

Key aspects of domain-based access:

  • Federated control: Domain owners have authority over data permissions within their domains.

  • Layered governance: Domain governance teams manage permissions for their specific data, while a higher-level governance team oversees cross-domain access.

  • Scalability: This model is well-suited for large organizations with multiple domains or business units.

Using Data Policies Instead of Subscription Policies

In some scenarios, organizations may choose to relax subscription policies and focus on data policies instead. For instance, if appropriate masking or row-level filtering is already in place, subscription policies can be more general, allowing access to larger groups. The data policies then take over, ensuring that users only see the data they are permitted to view based on their attributes.

This pattern is particularly useful when:

  • General access is granted to a broad user base, but visibility of sensitive data is restricted through masking and filtering.

  • Established workflows already control access, and subscription policies are used for broader access definitions.

Read vs Write Subscription Policies

Immuta allows organizations to manage both read and write access through subscription policies, providing granular control over who can view or modify data objects. These controls can be applied at the table, view, or object level.

  • Read Policies: Define who is permitted to query and view data. This allows organizations to restrict visibility to specific users or groups based on their roles or attributes.

  • Write Policies: Govern who is allowed to create, modify, or delete data objects within integrated platforms like Snowflake, Databricks, and Unity Catalog. Write policies are critical for managing data modifications, ensuring only authorized users can alter data or create new objects.

By implementing both read and write subscription policies, organizations can ensure comprehensive control over data access and modification, tailoring permissions to meet the needs of different roles and ensuring that only the appropriate users can perform sensitive actions.

Conclusion

Subscription policies in Immuta are a powerful tool for managing access to data objects. By combining these policies with data policies, organizations can ensure that users only access the data they need, while protecting sensitive information. Whether you’re using birthright access, implementing a data mesh model, or relying more heavily on data policies, subscription policies provide the flexibility to meet a wide range of governance needs.

Last updated

Was this helpful?