Here's an overview of how we ensure that only authorized customers can share their code with us and how we tightly control access to these images.

How We Securely Run Customer Code in our Service: A Technical Overview

At LifeOmic, we understand that our customers may have proprietary code that they want to run within our services. To facilitate this, we’ve created a way for our customers to securely share their own Amazon Elastic Container Registry (ECR) images with us, so we can run their code within our Patient ML Service. Here’s an overview of how we ensure that only authorized customers can share their code with us and how we tightly control access to these images.

Threat Models

Before we dive into the technical details of how we’ve set up this system, let’s first consider a few potential threat models:

• A malicious customer, who wants to exploit access to a competitor’s proprietary code that they have obtained.
• A malicious customer, who wants to run their own proprietary code on another customer’s data.
• A malicious customer, who has obtained (perhaps through espionage) the image URI for another customer’s proprietary code.

Our goal is to ensure that our system is designed to prevent any malicious customers from running unauthorized code within our service.

How it Works

To accomplish our goal, we’ve created a process that requires our customers to share their own ECR images with us, while also tightly controlling access to those images. Here are the steps involved:

1. The customer must allow our AWS account to pull their ECR image by creating an ECR repository and adding a policy to that repository, which grants our AWS account permission to pull that image. This policy ensures that only our account can pull the customer’s image. Here’s an example policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Pull",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::623119755067:root"
      },
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:BatchGetImage",
        "ecr:DescribeImages",
        "ecr:GetDownloadUrlForLayer",
        "ecr:ListImages"
      ]
    }
  ]
}

2. The customer then shares their ECR image URL with us. From this URL, we can deduce the image’s Amazon Resource Name (ARN), which uniquely identifies the image in the customer’s AWS account.

3. We then create an ephemeral AWS Identity and Access Management (IAM) policy that allows our service to pull and run that specific image. This policy is valid only for the duration of the SageMaker training job, or for the lifespan of the SageMaker endpoint instance, and grants access only to the image specified by the customer. This policy ensures that we can’t pull any other images from the customer’s ECR repository, and that other customers can’t share images with us unless they’ve explicitly added our AWS account to their ECR repository policy.

By tightly controlling access to the customer’s ECR images and only allowing our AWS account to pull and run authorized images, we’ve created a secure way for our customers to run their own proprietary code within our Patient ML Service. This not only enables our customers to leverage the power of our service, but also ensures that they can do so without compromising the security of their own code.

Conclusion

At LifeOmic, we take the security of our customers’ code very seriously. By creating a secure way for our customers to share their own ECR images with us, we’ve ensured that only authorized customers can run their code within our services. This not only helps our customers unlock the full potential