Bitfount Pod Policies
A key feature of Bitfount’s federated data science platform is its ability to enable Pod owners to ‘authorise’ policies against Pods. You can think of policies as rules which dictate who has access to a Pod and what tasks can be performed against it.
Bitfount has designed policies to be flexible according to the relationship between parties accessing the data, the data custodian’s risk posture in relation to its collaborators, and the use cases the data custodian wishes to support by activating a Pod. All available policies and policy permissions are outlined below with descriptions and example use cases.
Bitfount Policy Hierarchy
Data Custodians have the opportunity to authorise usage-based access control policies against Pods depending on the relationship between the Custodian and their collaborators.
Today, this is largely based on controls a Custodian would like to enforce in relation to individual users. In the future, these controls will extend to organisations, advanced use cases, and future techniques for enforcing privacy. In the meantime, it’s helpful to think of Bitfount policies as dictating who has access to a given Pod, what tasks or use cases they can perform once they have access, and how those tasks can be performed.
Instructions for granting or revoking access can be found in Authorising Pods.
Usage-Based Control Policies
Usage-based control policies focus on the purpose of access based on a collaborator’s given role in relation to the Pod. In order to apply usage-based controls, a Pod owner must assign a role to each collaborator who will access the Pod. You can think of a role as a collection of permissions which dictate how the collaborator can interact with the dataset associated with the Pod.
Roles are associated with a set of default permissions (see permissions sections below for greater detail), which you can think of as rules that enforce how the authorised collaborator can interact with the dataset associated with the Pod.
Bitfount currently supports several default roles to which collaborators may be assigned:
| Role | Description | Default Permissions | When to Apply |
|---|---|---|---|
| Super Modeller | This modeller can perform any modelling task supported by Bitfount on the selected pods. WARNING: Super Modellers are allowed to use any custom models or arbitrary code. Bitfount does not vet the contents of custom models, so Data Custodians should be confident in the model(s) prior to granting this role. | Protocols: - Any Bitfount-installed protocol Algorithms: - Any installed algorithm Models: - Any installed model - Any custom model | This role is best assigned to users with whom a Data Custodian has full trust. |
| General Modeller | This modeller can perform any modelling task supported by Bitfount on the selected pods, apart from running the ModelInference or SqlQuery algorithms and furthermore the PrivateSqlQuery algorithm is limited to a DP epsilon of 10. Finally, custom models are not permitted by default but the modeller can still request extra access for a specific custom model. | Protocols: - Federated averaging - Results only - Private Set Intersection Algorithms: - Train - Evaluate - Train and evaluate - Private SQL - Compute Intersection RSA Models: - Any installed model | This role is best assigned to users with whom a Data Custodian has a high level of trust. |
| DP Restricted Modeller | This modeller can only perform modelling tasks on the selected pods with the restriction that Differential Privacy must be enforced and the parameter epsilon expended in the modelling task is less than or equal to 3. No custom model permissions can be added to this role as we cannot guarantee that differential privacy will be enforced. | Protocols: - Federated averaging - Results only Algorithms: - Train - Evaluate - Train and evaluate - Private SQL Models: - Any installed model | This role is best assigned to users for whom a Data Custodian would like to impose additional privacy-preserving techniques to mitigate the risk of privacy leakage. |
| Metrics Only | This user can only perform tasks on the selected pods that return evaluation metrics. | Protocols: - Results only Algorithms: - Evaluate - Train and evaluate Models: - Any installed model | This role is best assigned to users with whom a Data Custodian has a lower level of trust or to those who do not need to leverage advanced algorithms. |
| Viewer | This user can see the selected pods on the Explore page and on their profile pages in the Bitfount Hub | View-only | This role is best assigned to users who want to monitor Pod activity but who will not need to interact with data. |
By granting access to a Pod, you are agreeing that grantees are able to perform tasks against it as well as any Pods to which they also have access. Grantees can only perform tasks according to the role you assign them. Note, multi-Pod tasks can only be performed against Pods with the same column layout and unique values within the columns.
Don’t see a role or capability listed here? Have an additional use case that you’d like to see enabled? We’d love to hear your feedback via support@bitfount.com.
Task Permissions
Each role is associated with a set of task permissions, which you can think of as dictating what types of interactions a given collaborator can have with a dataset associated to a given Pod. Tasks currently fall into three categories:
- Protocols: The protocol defines how communication is orchestrated between Pods and the Data Scientist.
- Algorithms: The algorithm defines what computation is done on each Pod at each iteration of a protocol
- Models: The model is a parameter to Model-based algorithms. For this class of algorithm, the model is the model architecture used for doing the analysis.
The Bitfount package a user installs comes pre-loaded with a set of default protocols, algorithms, and models Bitfount has vetted for use with the platform. More details on the contents and recommended use of these task types can be found in Bitfount Task Elements.
Privacy-Preserving Permissions
These permissions reflect privacy-enhancing techniques a Data Custodian may wish to apply to a Pod depending on their risk posture or relationship to the Data Scientist. Note that a Data Scientist can run privacy-preserving tasks without the need for privacy-permissions to be set if they wish to test this capability.
Beyond the privacy-preserving techniques ingrained in the Bitfount-installed protocols, Bitfount supports a role, DP Restricted Modeller, with a differential privacy budget (epsilon) of 3 already applied. This means that the Data Scientist will need to specify a value of epsilon, which will dictate the level of noise added to the task outputs, when performing a task.
Interacting With Privacy-Preserving Permissions
Bitfount currently does not support configurable privacy-preserving permissions. Instead, if a Data Custodian wishes to apply differential privacy to their Pod, a budget of 3 will be set against the Pod.
For details on how to run a task with a differentially private output, please see our Differential Privacy tutorial.
Policy Conflicts
Sometimes, a user attempts to interact with Pods in an un-authorised manner or is unable to execute a task because they’ve been throttled by privacy-preserving permission constraints. If you are the Data Custodian, you may choose whether or not to relax the Pod policies in order to resolve the conflict based on your own risk posture. If you are the Data Scientist and cannot be granted fewer restrictions, check out our Obtaining Pod Permissions & Understanding Pod Metadata guide for helpful tips on how to adjust your queries to meet policy requirements given your use case.
Still have questions on policies? Check out our Troubleshooting & FAQs guide or reach out to us via support@bitfount.com