MLSpace Security Introduction

MLSpace adheres to the principle of least privilege, a fundamental security concept that grants users or processes only the minimum level of access and authority required to perform their designated functions. This approach significantly reduces the risk of unauthorized access and potential malicious activities. MLSpace implements this principle through various mechanisms, all of which are governed by the strategic use of AWS IAM Roles and Policies.

TIP

For a comprehensive overview of AWS Identity and Access Management (IAM), please consult the official AWS IAM documentation. For a concise introduction, we recommend reviewing our Basic IAM Guide.

Security Best Practices

Least Privileged Policies

To ensure robust security, MLSpace adopts a least privileged approach when setting permissions with IAM policies. This involves granting only the necessary permissions required to perform a specific task. We define the actions that can be taken on specific resources under specific conditions, thereby minimizing the risk of unauthorized access.

Policies are carefully scoped to only allow activated services as defined by the application configuration, which is accessible only to authorized administrators. Furthermore, user-scoped policies are updated in realtime to scope user's roles to the minimum permissions necessary to perform their duties and limited by the permission set defined in the application's permission boundary.

Conditional Permissions

MLSpace employs conditional permissions to enhance security and access control. These conditions specify the circumstances under which policy statements become effective, allowing for more granular and context-aware access management.

For instance, MLSpace frequently utilizes conditions to restrict users' interactions to resources tagged with their username or associated with projects or groups of which they are members. This approach ensures that users can only access and manipulate resources relevant to their roles and responsibilities, thereby maintaining the principle of least privilege and reducing the potential for unauthorized access or accidental modifications.

While this approach requires the iam:CreateRole action, MLSpace employs conditional permissions to constrain the application to only creating and modifying roles with a specified prefix. This ensures a very limited scope of operation, further enhancing security measures.

By implementing these conditional permissions, MLSpace achieves a balance between flexibility and security, allowing for Secure User Scoped Roles creation while maintaining strict control over the extent of these roles' capabilities.

Permissions Boundaries

Permissions boundaries are an advanced feature that allows for the delegation of permissions management within an account while maintaining control over maximum permissions granted. This feature is particularly useful when you need to delegate permissions to others, such as allowing developers to create and manage roles for their workloads.

A permissions boundary utilizes a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM role. It's important to note that a permissions boundary itself does not grant permissions; rather, it acts as a limit on the permissions that can be granted.

For a more comprehensive understanding of permissions boundaries, please refer to the AWS documentation on Permissions boundaries for IAM entities.

Immediate deletion of unnecessary Roles/Policies

When a user's membership changes with a Group, Dataset, or Project, MLSpace immediately removes any unnecessary roles, scopes down IAM policies to ensure least-privilege permissions, and restricts access to resources, ensuring that access is only granted to what is required for the user's new role. This proactive approach helps maintain the security and integrity of your AWS account by minimizing the attack surface and reducing the risk of unauthorized access.

Role Descriptions

Role	Policies	Description
Appliation	Application, Notebook, Service Configuration, Endpoint Configuration, Job Configuration, KMS, AWSLambdaVPCAccessExecutionRole	The application role is used for general anything that have no associable user. Things like querying for all Projects a user is a member of or creating a new Dataset for a user.
System	System, Notebook, AWSLambdaVPCAccessExecutionRole	This role will provision permissions to the MLSpace system to perform actions independently of what users are capable of doing. Ex: a service like EMR may be disabled, but this role will allow the system to terminate EMR clusters even though users can't perform any EMR actions. These actions include cleaning up resources for deleted projects and suspended users.
Notebook	Notebook, Service Configuration, Endpoint Configuration, Job Configuration, KMS, AWSLambdaVPCAccessExecutionRole	The permissions necessary to call activated AWS services from within a Notebook.
S3 Reader	S3 Reader	Role used to serve MLSpace website from S3
Scoped User	User, Project, Notebook, Service Configuration, Endpoint Configuration, Job Configuration, KMS	Similar to the Notebook policy but scoped to an individual user to maintain the principle of least privileged.

Policy Descriptions

Policy	Description
Application	The Application role serves as the most comprehensive role within the MLSpace application. It encompasses the necessary permissions for the majority of AWS Lambda functions utilized throughout MLSpace, as well as for tasks that are not associated with a specific user. Examples of such tasks include querying all projects a user is a member of or creating a new dataset on behalf of a user.
System
Notebook
Service Configuration
Endpoint Configuration	The Endpoint Instance Constraint Policy is designed to restrict users to creating SageMaker Endpoints using only approved instance types. This policy ensures that resource allocation aligns with organizational guidelines, promoting cost control and performance optimization across MLSpace.
Job Configuration	The Job Instance Constraint Policy restricts users to creating Training, Hyperparameter Optimization (HPO), and Transform jobs using only approved instance types. This policy ensures that resource allocation aligns with organizational guidelines and helps maintain cost control and performance optimization across MLSpace.
KMS	This KMS policy enforces the use of a KMS key for SageMaker resources that utilize instance types supporting EBS volume encryption. Conversely, it allows SageMaker resources that provide their own volume encryption keys to operate without requiring a KMS key. This policy ensures appropriate encryption practices are maintained across different SageMaker resource configurations.
S3 Reader	Allows reading from S3 bucket
AWSLambdaVPCAccessExecutionRole	Provides minimum permissions for a Lambda function to execute while accessing a resource within a VPC - create, describe, delete network interfaces and write permissions to CloudWatch Logs.
User	User policies govern access to specific S3 path prefixes tailored to individual users. These policies also enforce appropriate resource tagging, ensuring accurate attribution of resources within the system.
Project	Project policies provide access to specific S3 path prefixes designated for Project scoped Datasets and enforced that resources are tagged appropriate for assured attribution.
Project User Permission Boundary	The maximum permission boundary defined for a MLSpace USER