Four authentication methods StarRocks Cloud Native supports

Introduction

StarRocks Cloud Native Edition support access to resources on public clouds, so security is a very important aspect. This document provides four authentication methods supported while deploying StarRocks Cloud Native Edition on AWS.

Method 1: Using AK / SK (Access Key and Secret Key)

This is also the least secure method. By configuring the AK/SK key pair on the FE node , it will distribute the AK/SK key pair to the BE computing node during system operation. The BE node then passes the AK/SK to the AWS SDK to access cloud resources. This is the easiest method to use but has the lowest security factor. Once the AK/SK is leaked, it will have a severe impact and is not recommended to use.

Method 2: Using Instance Profile

This method involves creating an instance profile for EC2 instances in the cloud environment, and configuring the profile with permissions to access specific resources. In this way, instances with this profile can access the corresponding resources. The steps of this operation are:

1. Create a service role with type ‘AWS Service’:

2. Add full access permission to S3 service for role, as shown in the following picture:

3. Naming the role:

4. You can view the details of the newly created service role on the AWS console:

5. Attach the role created above to EC2 that needs access to AWS resources. In the following image, select “Modify IAM role” and in the drop-down box, select the service role just created.

6. Once completion, you can view the attached profile in the EC2 detail page:

After finishing the above steps, configure the authentication method and enable instance_profile property during creating storage volume:

CREATE STORAGE VOLUME jeff_s3_volume
TYPE = S3
LOCATIONS = s3://jeff_bucket/starrocks/
PROPERTIES (
  "aws.s3.region" = "<region>",
  "aws.s3.endpoint" = "<endpoint_url>",
  "aws.s3.use_aws_sdk_default_behavior" = "false",
  "aws.s3.use_instance_profile" = "true",
)

This method is much more secure than the first method, but there are problems such as abuse of power. Use it with caution and it is not the best way we recommend.

Method 3: Using Instance Profile and Assume Role

In method two, a service role with high privileges is created and attached to the EC2, giving the EC2 the corresponding privileges, but this is not the best way either. We generally recommend using the Instance Profile plus Assume Role method for authentication and access control.

The AWS Assume Role mechanism allows a service or user entity to take on a certain role, thereby having the permissions of that role. Because you can dynamically control the types and number of roles played, it is very flexible in actual use and brings the maximum level of security.

To use this mechanism, you first need to create a role with no permissions. The steps are as follows:

1. Create a role with no permissions, as shown in the following image:

2. Select permissions, note that at this time no permissions need to be selected. This is one of the differences from method two.

3. Give it a name and complete the creation

4. Next, you can see detailed information of the role on the console:

5. Next, attach the newly created role to EC2 that needs to access to resources, the steps are the same as method two, it will not be repeated here. After the attachment is completed, the effect is as follows:

6. Then, the newly created role needs to be configured so that assume role operations can be performed. The steps are as follows:

• Add permissions to the newly created role.

It means allowing the role ‘jeff-test-role-no-policy’ to assume the target role ‘arn:aws:iam::081976408565:role/CELERDATA_Data_Role’, so that it can access resources that the target role has access to. Therefore, you need to create the target role and define its access permissions beforehand. After it is created, the effect will be as follows:

• The next step is to configure the role that will be assumed by ‘jeff-test-role-no-policy’ , specifically, by modifying the following fields:

• Add the ARN of the role that it is allowed to assume, as shown in the blue box in the following picture:

After completing the above configuration, the environment configuration is complete. Then you can create storage volume like this:

CREATE STORAGE VOLUME jeff_s3_volume
TYPE = S3
LOCATIONS = s3://jeff_bucket/starrocks/
PROPERTIES (
  "aws.s3.region" = "<region>",
  "aws.s3.endpoint" = "<endpoint_url>",
  "aws.s3.use_aws_sdk_default_behavior" = "false",
  "aws.s3.use_instance_profile" = "true",
  "aws.s3.iam_role_arn" = "arn:aws:iam::081976408565:role/CELERDATA_Data_Role"
)

Please note that the iam_role_arn should be configured as the ARN of the assumed role.

Method 4: Web identity

This method allows pods in EKS to access S3 objects, in support of deploying StarRocks Cloud Native clusters directly in EKS environments. The main steps of the operation will be describiled in next document.