Foundry Identity and Access Management (IAM)

Overview

Foundry offers a structured and simplified approach to permissions for streamlined management and implementation. By focusing on an organization and project-centric model, Foundry establishes clear boundaries of authority and access.

Note, while the Foundry IAM system is highly extensible and allows complex and granular access control, we work directly with users to implement the simplest role and permissions hierarchy that meets their organizational needs. We believe that simplicity = greater security. Security solutions that emphasize management simplicity not only reduce costs and save time and effort, but also reduce misconfiguration risk. Since Foundry is a dedicated platform for machine learning, much of the language and complexity around applications, workloads, etc that you find in GCP and AWS (designed with web applications and services in mind) can be discarded in favor of a simpler model centered on projects.

While Foundry has a default system and nomenclature, we also flexibly allow users to port their IAM structures from other platforms like AWS and GCP directly, and can help them integrate with multi-protocol access proxy solutions like teleport.

Entities in Foundry

1. Organization

2. Project

3. User

4. Resource

   • This includes instances, jobs, storage, keys, and more.

Relationship Between Entities:

• Users are affiliated with an organization.

• Projects are tied to an organization.

• Resources are associated with a specific project.

• Users have access to selected projects within their organization and can access all resources within those projects.

User Types in an Organization

1. Administrators:

   • Can invite new members to the organization.

   • Can modify any team member's role in the organization.

   • Have the authority to view and modify billing details, settle invoices, and initiate new projects.

   • Can add or remove team members from projects.

   • Have access to all projects within the organization.

2. Members:

   • Their permissions are dependent on the projects they are added to by the administrator(s).

   • Within the projects they're affiliated with, members possess complete operational capabilities, such as creating, starting, stopping, and terminating instances.

Key Considerations

• By design, granular access to specific resources within a project isn't permissible. If users require the above functionalities, they are likely in a scenario where they should consider segregating the project into smaller projects with atomic permissions.

• The design choice to prioritize organization administrators over project administrators is to centralize billing and access control. This ensures that only qualified individuals with granted permissions can interact with the system once added to a project.

• Aligning everything around organizations and projects—and allowing each user to be part of just one organization—prevents a user from handling both personal and professional tasks under a single Foundry account. This separation helps prevent inadvertent operations in the wrong context, similar to AWS's model.

Porting IAM roles, permissions from other clouds (e.g., AWS & GCP)

For user convenience, we allow users to port their existing IAM roles, permissions, etc. from AWS or GCP to use in Foundry. We work with users to facilitate this directly. This process requires some bespoke work and the leveraging of an intermediary system to map permissions and roles from AWS/GCP to our application.

Here's a high-level outline of the process:

1. Getting permission data from AWS or GCP: We'll need to access the user's IAM roles, policies, and permissions from their AWS or GCP accounts. For AWS, we can use the AWS SDK or CLI to access IAM information. We'll need to use API calls like list_roles, get_role, list_policies, get_policy, and get_policy_version to collect IAM roles and policies. We may need the user's access key and secret key to authenticate to their account. For GCP, we can use the Google Cloud SDK or the REST API to access IAM information. We'll use API methods like projects.getIamPolicy, roles.list, and permissions.queryTestablePermissions to collect roles and permissions. We may need the user's OAuth 2.0 credentials or service account key for authentication.

2. Mapping AWS/GCP permissions to our application: Once we have the IAM information, we leverage a mapping system that translates the AWS/GCP roles and permissions into corresponding roles and permissions within our application.

3. Applying the mapped permissions: Finally, we'll apply the mapped permissions and roles to the user's account in our application. We'll ensure that the user's access and actions in our application are appropriately controlled by the ported IAM roles and permissions.

It's important to note that porting IAM roles and permissions across different platforms may not be a perfect process, as each platform's access control model might be different. We thus thoroughly test and validate the permissions in our application to ensure they're working as expected.

Special Mention: SSH Keys:

• While SSH keys should ideally be unique to a user, Foundry does not enforce this.

• Foundry advises users to create a key upon registration. We store the public key at the project level, and upon instance creation, users may enable any keys from the given project to have access to the instance.

• Importantly, Foundry never retains private keys generated through the UI or enables the sharing of them between users within a project. The management of private keys remains the responsibility of the customer.