Accessing Amazon Secrets Manager
This version of the Anyscale docs is deprecated. Go to the latest version for up to date information.
This section provides instructions on configuring access to Amazon Secrets Manager for Anyscale clusters. Accessing stored secrets in Amazon Secrets Manager is often necessary for various workloads and clusters. The configuration process involves two key steps:
- Policy Assignment for IAM Role: Ensure that the IAM Role associated with Anyscale Clusters has the appropriate IAM policies for reading secrets.
- (Optional) Resource Policy for Secrets:: Optionally, the Resource Policy associated with the secret may require modification to grant access permissions to the IAM Role used by Anyscale Clusters.
The following documentation will guide users through these steps to facilitate secure and effective integration with Amazon Secrets Manager.
Configure IAM Role
Required Information
- Secret ARN: This
ARN
will look likearn:aws:secretsmanager:<region>:<account_id>:secret:<secret_name>
. - The IAM Role that the cluster is running with.
Determine the Cluster's IAM Role
By default, Anyscale clusters run with a cloud-specific IAM role.
If you followed instructions on how to run with a custom IAM role, use that role for the rest of the instructions.
Ensure the Cluster's IAM Role has access to your Secret
- In the AWS console, go to the IAM Roles console
- Search for the Cluster role and select it.
- Add an inline policy to the role. This policy will grant read access to the Amazon Secret.
- In the Permissions tab, click Add permission and then Create inline policy.
- Click on the JSON tab
- Use the following JSON as a starting point - make sure to modify
<secret-arn>
with your Secret's ARN.
{
"Statement": [
{
"Action": ["secretsmanager:GetSecretValue"],
"Effect": "Allow",
"Resource": ["<secret-arn>"],
"Sid": "SecretsManagerGetSecretValue"
}
]
}
- (Optional) You may need to update or attach a resource-based policy to the Secret. Please refer to the AWS Secrets Manager Policy documentation
More information on managing IAM Policies associated with IAM Roles can be found in the AWS IAM documentation.
More information and additional example Secrets Manager policies can be found in the AWS Secrets Manager documentation.
Using Secrets
There are several ways that Secrets can be utilized with clusters and applications running with Anyscale. Here is an example:
Cluster Initialization Scripts
Cluster Init Scripts are part of an Anyscale Cluster Environment. These shell scripts run on all nodes in a cluster after the node is started, but before Ray starts. This gives you a very flexible way to integrate third-party tools, clone private git repos, or perform other application startup requirements. Init scripts need to be created inside the folder /anyscale/init
.
Here is an example of using a init script to retrieve a GitHub Personal Access Token stored in Secrets Manager, and perform a git clone of a private git repo.
- Create a Personal Access Token in GitHub, granting it permissions to read from your private GitHub repository.
- Create a Cluster Environment using either a Custom Docker Image hosted in ECR, or a standard Cluster Environment using a YAML file for the definition.
- Follow one of the following examples to create a Cluster Environment.
- Cluster Environment
- Custom Docker Image
base_image: anyscale/ray:2.9.0-py310
env_vars:
PRIVATE_REPO_NAME: <your_private_repo>
SECRET_NAME: <example_secret/github_token>
AWS_DEFAULT_REGION: <your_aws_region>
debian_packages:
- jq
post_build_cmds:
- sudo mkdir -p /anyscale/init
- sudo touch /anyscale/init/github_clone.sh
- echo 'mkdir -p $ANYSCALE_WORKING_DIR && cd $ANYSCALE_WORKING_DIR' | sudo tee -a /anyscale/init/github_clone.sh
- echo 'SECRET_VALUE=$(aws secretsmanager get-secret-value --secret-id ${SECRET_NAME} | jq -r .SecretString)' | sudo tee -a /anyscale/init/github_clone.sh
- echo 'GITHUB_TOKEN=$(echo ${SECRET_VALUE} | jq -r .github_token)' | sudo tee -a /anyscale/init/github_clone.sh
- echo 'git clone https://${GITHUB_TOKEN}@github.com/${PRIVATE_REPO_NAME}' | sudo tee -a /anyscale/init/github_clone.sh
You will need to create both the dockerfile
and the github_clone.sh
files before building the Docker image. Here is an example dockerfile
:
# Use Anyscale base image
FROM anyscale/ray:2.9.0-py310
RUN sudo apt-get update && sudo apt-get install -y axel nfs-common zip unzip && sudo apt-get clean
# Required for this example
RUN sudo apt-get install -y jq git curl && sudo apt-get clean
# AWS CLI installation commands for AWSCLIv2
RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
RUN unzip awscliv2.zip && sudo ./aws/install
RUN pip install --no-cache-dir -U sympy anyscale
ADD ./github_clone.sh /anyscale/init/github_clone.sh
# (Optional) Verify that dependencies from the base image still work. This
# is useful for catching dependency conflicts at build time.
RUN echo "Testing Ray Import..." && python -c "import ray"
RUN ray --version
RUN jupyter --version
RUN anyscale --version
RUN sudo supervisord --version
RUN aws --version
Here is an example github_clone.sh
:
#/bin/bash
# PreReqs: awscli, jq
# Env Variables required: ANYSCALE_WORKING_DIR, SECRET_NAME, PRIVATE_REPO_NAME, AWS_DEFAULT_REGION
# Create and then change directories into the working directory - either default or project_name
mkdir -p $ANYSCALE_WORKING_DIR
cd $ANYSCALE_WORKING_DIR
SECRET_VALUE=$(aws secretsmanager get-secret-value --secret-id ${SECRET_NAME} | jq -r .SecretString)
GITHUB_TOKEN=$(echo ${SECRET_VALUE} | jq -r .github_token)
# Clone the repo
git clone https://${GITHUB_TOKEN}@github.com/${PRIVATE_REPO_NAME}
Once your Docker file is built, you can follow our guide for Bringing your own Docker, making sure to set the environment variables: SECRET_NAME
, PRIVATE_REPO_NAME
, and AWS_DEFAULT_REGION
.