Exchanging Data with Recast
Clients must provide Recast with data updates to support model refreshes, and may also (optionally) receive model output data back from Recast. Recast supports many options for this data exchange, including both Recast-managed and client-managed data repositories, as well as third-party services. All of the currently supported options are listed below, as well as details of the setup process and requirements for each, particularly in regard to security and authentication.
Recast is continually implementing new data exchange options based on client needs, so if you don’t see an option below that works for your organization, please inquire. However, implementing new options is likely to extend onboarding timelines, so utilizing one of the options listed below whenever possible is encouraged.
The “On this Page” navigation pane to the right provides a list of the currently supported data repositories with links to quickly access those sections of this page for more information about each option.
Recast-Managed Data Repositories
AWS S3
Clients may transfer data to and from an AWS S3 bucket in Recast’s AWS account.
This option is often preferred by clients who have their own AWS account (but don’t want to manage the S3 bucket used for data exchange with Recast) or who are using a third-party service which offers an “S3 connector”.
Two authentication methods are supported, with the details of each covered below.
IAM Role (strongly preferred)
Recast can create an IAM role which may be assumed from the client’s AWS account or the AWS account of a third-party service being utilized by the client. Once the role is assumed, access to Recast’s S3 bucket will be available.
In order to create the IAM role, Recast needs to know the following information:
Required: The AWS account number which the role will be assumed from.
Optional: The ARN of the client’s IAM user or role which will be assuming Recast’s IAM role. If not provided, Recast will allow any IAM user or role in the client’s AWS account to assume Recast’s IAM role.
Optional: The “external ID” included in requests made by the client’s IAM role to assume Recast’s IAM role. The use of an external ID is an additional security measure most appropriate when utilizing a third-party service to connect to Recast’s S3 bucket. The third-party service will provide this external ID (generally when configuring the S3 connector). Recast strongly discourages the use of any third party service which does not support an external ID for S3 connectors. For connections from client-managed AWS accounts, an external ID is less critical but is also supported.
Once Recast completes setup of the IAM role, Recast will provide the IAM role’s ARN to the client.
The following is a summary of the setup information to be exchanged between Recast and the client.
Client provides to Recast:
The account number of the client’s AWS account which Recast’s IAM role will be assumed from. (required)
The ARN of the client’s IAM user or role which will will be assuming Recast’s IAM role. (optional)
The external ID included in requests made by the client’s IAM role to assume Recast’s IAM role. (optional)
Recast provides to client:
The ARN of Recast’s IAM role which the client will be assuming.
The bucket name of Recast’s S3 bucket.
The path in the S3 bucket where the client will write and read data.
IAM User (supported but strongly discouraged)
Recast can create an IAM user with an access key which may be used to access Recast’s S3 bucket. The use of an IAM user provides great flexibility in the methods used to access Recast’s S3 bucket for clients who do not have their own AWS account, including programmatic access via the AWS API, command-line access via the AWS CLI, and third-party “S3 connectors”.
Although this option is supported, and even sometimes necessary given some current client constraints, Recast strongly discourages its use because access via an IAM user is more difficult to secure than access via an IAM role. Instead, Recast recommends the use of an IAM role (for clients with their own AWS account) or SFTP (for clients without their own AWS account) whenever possible.
Additionally, Recast’s security policies require IAM user access keys to be rotated periodically, which necessitates ongoing maintenance and may also disrupt scheduled data exchanges and model refreshes if the key rotation is not handled in a timely manner.
Recast does not require any information from the client in order to set up an IAM user for the client.
Once Recast completes setup of the IAM user, Recast will provide the IAM user’s access key and the S3 bucket name and path to the client.
This information must be communicated securely, through a service such as onetimesecret.com, or some other secure messaging channel.
The following is a summary of the setup information to be exchanged between Recast and the client.
Recast provides to client:
The Access Key ID and Secret Access Key of Recast’s IAM user which the client will use to access Recast’s S3 bucket.
The bucket name of Recast’s S3 bucket.
The path in the S3 bucket where the client will write and read data.
SFTP
Clients may transfer data to and from an SFTP server managed by Recast, with an SFTP user set up by Recast.
This option is often preferred by clients who do not have their own AWS account, who have an established pattern of utilizing SFTP for data transfers, or who are using a third-party service which offers an “SFTP connector”.
Two authentication methods are supported, with the details of each covered below.
Key-Based Authentication (strongly preferred)
Recast supports and recommends key-based authentication for SFTP.
In order to set up an SFTP user for the client using key-based authentication, the client must create an SSH key pair and provide Recast with its public key. (The client should not share the private key, and should store the key pair securely.)
After Recast receives the public key from the client and completes setup of the SFTP user, Recast will provide the client with the information necessary to access the SFTP server, including hostname (sftp.getrecast.com), port (22), and username.
The following is a summary of the setup information to be exchanged between Recast and the client.
Client provides to Recast:
The public key from the client-generated SSH key pair.
Recast provides to client:
The SFTP host name.
The SFTP port.
The SFTP username.
Password Authentication (supported but strongly discouraged)
Recast supports, but does not recommend, password authentication for SFTP.
Although this option is supported, Recast strongly discourages its use because password authentication is less secure than key-based authentication.
Additionally, Recast’s security policies require SFTP passwords to be rotated periodically, which necessitates ongoing maintenance and may also disrupt scheduled data exchanges and model refreshes if the key rotation is not handled in a timely manner.
Recast does not require any information from the client in order to set up password authentication.
Once setup of the SFTP user is complete, Recast will provide the client with the information necessary to access the SFTP server, including hostname (sftp.getrecast.com), port (22), username, and password.
This information must be communicated securely, through a service such as onetimesecret.com, or some other secure messaging channel.
The following is a summary of the setup information to be exchanged between Recast and the client.
Recast provides to client:
The SFTP host name.
The SFTP port.
The SFTP username.
The SFTP password.