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 task on the selected pods and get back model weights and metrics. WARNING: Super Modellers are allowed to use custom models. 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: - Federated averaging - Results only - Any Bitfount-installed protocol Algorithms: - Train - Evaluate - Train and evaluate - 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. It is necessary to assign this role if a user will need to run custom models as part of their analysis. |
| General Modeller | This modeller can perform any modelling task on the selected Pod(s), apart from running custom models, and get back model weights and metrics. | Protocols: - Federated averaging - Results only - Any installed protocol Algorithms: - Train - Evaluate - Train and evaluate - Any installed algorithm Models: - Any installed model | This role is best assigned to users with whom a Data Custodian has a high level of trust but who do not need to run custom models. |
| DP Restricted Modeller | This modeller can perform any modelling task on the selected pods, apart from running custom models, and get back model weights and metrics with the restriction that the Differential Privacy parameter epsilon expended in the modelling task is less than 3. | Protocols: - Federated averaging - Results only - Any installed protocol Algorithms: - Train - Evaluate - Train and evaluate - Any installed algorithm 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 perform any task on the selected Pod(s), but can only receive evaluation metrics back. | 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 Pod(s) 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. |
⚠️ WARNING: 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 on our community Slack channel.
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 Privacy Preserving Techniques tutorial.
Policy Conflicts
Sometimes, a user attempts to interact with Pods in an unauthorised 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 in our Bitfount Community Slack.