Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

   

For the latest updates on available API endpoints and documentation, see api.trifacta.com.

Contents:


Overview

The Trifacta® platform supports several methods of authenticating to AWS resources. At the topmost level, authentication can be broken down into two modes: system and user.
  • System mode: One set of credentials is used for each user of the platform to authenticate to AWS.
  • User mode: Individual user accounts must be configured with AWS credentials.

    NOTE: This section covers how to manage AWS credentials for individual users (user mode). When in system mode, please manage AWS configuration through the application.

Connection Methods

To connect to AWS resources and access S3 data, the following information is required for each user, depending on the method of connection.

AWS Key and Secret

If users are providing key-secret combinations, the following information is required. 

ItemDescription
key/secret(credential provider type is default) The AWS key and secret for the user to authenticate
default bucketThe default S3 bucket where the user can upload data and store generated results
extra bucketsAny extra S3 buckets to which the user should have access

AWS IAM Role ARN

Users can access AWS resources using IAM role ARNs that are associated with their accounts. 

At the API level, these roles can be associated with an AWSConfig object, which is then associated with users. Details are provided later. 

If users are using IAM roles to access, the following information is required. 

ItemDescription
active role

(credential provider type is temporary) The currently active IAM role to use to authenticate.

NOTE: If this information is not immediately available, a placeholder one is created when you create the configuration object. You can assign roles later. More information is provided below.

default bucketThe default S3 bucket where the user can upload data and store generated results
extra bucketsAny extra S3 buckets to which the user should have access


The above pieces of information must be provided for each user. To facilitate, the Trifacta platform supports the awsConfig object, which contains all of the above information. An awsConfig object is a set of AWS configuration properties that can be created, modified, and assigned to individual users via API. This workflow steps through that process.


Basic Workflow

  1. Acquire information.
  2. Locate the internal identifier for the user to which to assign the configuration object.
  3. Create an awsConfig object, assigning the object to the user as part of the process.
    1. If you are using IAM roles, you can create one or more awsRole objects to map to corresponding awsConfig objects.
  4. Modify the object as needed.

  5. Verify that the assignment is working.

Step - Acquire information

Acquire all of the information listed above for the awsConfig object you wish to create. In this example, the credential provider type is set to temporary, which means that authentication is determined by an IAM role.

Step - Locate user

Now, you need to locate the internal identifier for the user to which you wish to assign this AWS configuration.

Request:

Endpointhttp://www.wrangle-dev.example.com:3005/v4/people
AuthenticationRequired
MethodGET
Request Body

None.

 

Response:

Status Code200 - Ok
Response Body
{
    "data": [
        {
            "id": 3,
            "email": "4070250@example.com",
            "name": "Test User4070250",
            "ssoPrincipal": null,
            "hadoopPrincipal": null,
            "isAdmin": false,
            "isDisabled": false,
            "forcePasswordChange": false,
            "state": "active",
            "lastStateChange": null,
            "createdAt": "2019-04-16T16:27:51.143Z",
            "updatedAt": "2019-04-16T16:27:56.630Z",
            "outputHomeDir": "/trifacta/queryResults/4070250@example.com",
            "fileUploadPath": "/trifacta/uploads",
            "awsConfig": {
                "id": 2
            }
        },
        {
            "id": 2,
            "email": "32870@example.com",
            "name": "Test User32870",
            "ssoPrincipal": null,
            "hadoopPrincipal": null,
            "isAdmin": false,
            "isDisabled": false,
            "forcePasswordChange": false,
            "state": "active",
            "lastStateChange": null,
            "createdAt": "2019-04-16T16:27:19.511Z",
            "updatedAt": "2019-04-16T16:27:26.703Z",
            "outputHomeDir": "/trifacta/queryResults/32870@example.com",
            "fileUploadPath": "/trifacta/uploads",
            "awsConfig": {
                "id": 1
            }
        },
        {
            "id": 1,
            "email": "<admin_email>",
            "name": "Administrator",
            "ssoPrincipal": null,
            "hadoopPrincipal": null,
            "isAdmin": true,
            "isDisabled": false,
            "forcePasswordChange": false,
            "state": "active",
            "lastStateChange": null,
            "createdAt": "2019-04-16T07:44:04.299Z",
            "updatedAt": "2019-04-16T16:28:16.379Z",
            "outputHomeDir": "/trifacta/queryResults/admin@example.com",
            "fileUploadPath": "/trifacta/uploads",
            "awsConfig": {
                "id": 3
            }
        }
    ]
}

 

 

Checkpoint: In the above, you noticed that userId=2 is associated with awsConfig object id=1, which is the one you are replacing. This is the user to modify. Retain this value for later.

 

For more information, see API AWSConfigs Put v4.

Step - Create awsConfig object

Create the AWS configuration object.

NOTE: Optionally, the personId value can be inserted into the request to assign the AWS configuration object to a specific user at create time, when created by an admin user. If it is created by a non-admin user, the object is assigned to the user who created it, and the personId value is ignored.


Request:

Endpointhttp://www.wrangle-dev.example.com:3005/v4/awsConfigs
AuthenticationRequired
MethodPOST
Request Body
{
    "mode": "user",
    "credentialProvider": "temporary",
    "personId": 2,
    "role":"<my_iam_role>",
    "defaultBucket":"main_bucket",
    "extraBuckets":["extra-bucket1","extra-bucket2"]
}

Response:

Status Code201 - Created
Response Body
{
    "extraBuckets": [
        "extra-bucket1",
        "extra-bucket2"
    ],
    "id": 6,
    "defaultBucket": "main_bucket",
    "credentialProvider": "temporary",
    "externalId": null,
    "activeRoleId": "<my_iam_role>",
    "updatedAt": "2019-04-16T23:06:32.049Z",
    "createdAt": "2019-04-16T23:06:32.047Z",
    "credential": null
}

Checkpoint: In the above, the awsConfig object has an internal identifier (id=6). As part of the request, this object was assigned to user 2 personId=2. For more information, see API AWSConfigs Create v4.

Step - (optional) Assign awsRole object to awsConfig object

If your credential provider is set to temporary, you can create one or more awsRole objects. An awsRole object assigns an IAM role ARN to an awsConfig object. 

Since you can assign multiple awsRoles to an awsConfig, you can populate the set of available IAM roles for selection by individual users who have been assigned this awsConfig object.

NOTE: This section only applies of credentialProvider has been set to temporary for the object.

Tip: In the preceding step, when you created the awsConfig object and inserts an IAM role ARN for the activeRoleId value, an awsRole object was created for you, mapping the IAM role ARN to the awsConfig object. This step is only needed if you wish to add additional IAM role ARNs to the configuration object.

The following request creates the awsRole object and maps it to awsConfig id=6.


Request:

Endpointhttp://www.wrangle-dev.example.com:3005/v4/awsRoles
AuthenticationRequired
MethodPOST
Request Body
{
  "awsConfig": {
    "id": 6
  },
  "role": "<my_iam_role_arn_2>"
}

Response:

Status Code201 - Created
Response Body
{
    "createdFrom": "api",
    "id": 3,
    "role": "<my_iam_role_arn_2>",
    "awsConfigId": 6,
    "updatedAt": "2019-04-16T23:06:33.008Z",
    "createdAt": "2019-04-16T23:06:33.004Z",
    "deleted_at": null
}

Checkpoint: In the above step, you assigned an additional awsRole to the awsConfig object. For more information, see API AWSRoles Create v4.


Step - Modify awsConfig object

Suppose you realize that there is missing extra bucket (extra-bucket3) and that the role you specified is incorrect. You can use the following method to modify the created configuration object.

NOTE: When modifying an awsConfig object, you only need to include the parameters that you are modifying in the request. You must include the full value of the parameters, so all buckets must be listed in the following example.

Request:

Endpointhttp://www.wrangle-dev.example.com:3005/v4/awsConfigs/6
AuthenticationRequired
MethodPUT
Request Body
{
    "role": "<my_iam_role2>",
    "extraBuckets":["extra-bucket1","extra-bucket2", "extra-bucket3"]
}

Response:

Status Code200 - Ok
Response Body
{    "extraBuckets": [
        "extra-bucket1",
        "extra-bucket2",
        "extra-bucket3"
    ],
    "id": 6,
    "defaultBucket": "main_bucket",
    "credentialProvider": "temporary",
    "externalId": null,
    "activeRoleId": "<my_iam_role2>",
    "updatedAt": "2019-04-16T23:06:32.049Z",
    "createdAt": "2019-04-16T23:06:32.047Z",
    "credential": null
}


Step - Verify Authentication

To verify that the above configuration works:

  1. User id=2 should login to the application.
  2. User uploads assets through the Import Data page.
  3. User creates a short recipe that modifies these assets.
  4. User runs a job on that recipe to generate output to the default S3 bucket in CSV or JSON for downloading.
  5. User verifies that the results can be downloaded.

Checkpoint: You're done.

  • No labels

This page has no comments.