Connectors Hold the Credentials
Nội dung này hiện chưa có sẵn bằng ngôn ngữ của bạn.
Module 2 in the chapter The Doors In, chapter 4 of the Data 360 Architect course. Each module stands on its own. Previous: Pull or Push · Next: The Pull Door: Amazon S3
The question this module answers: Why does Data 360 keep credentials in a connector, set up once, and who should set it up?
When I first brought files in from Amazon S3, every data stream asked for the AWS keys again. Then Salesforce changed it. Now you create a connector once, it holds the credentials, and every stream after that just picks it. The great thing about that is I don’t have to keep plugging in my credentials.
Like a named credential
Section titled “Like a named credential”If you know the core org, think of a connector as kind of an equivalent of a named credential in Salesforce core. It holds the address and the secret for one outside system: the bucket and its keys, or the BigQuery project and its service account. It maintains the connection. Everything that uses that system refers to the connector by name, and nothing else needs to see the secret.
For Amazon S3, Salesforce’s setup page today walks through it: in Data Cloud Setup, under External Integrations, select More Connectors, then New, then Amazon S3. You name the connection, enter the authentication details and the bucket, and test the connection before you save. Salesforce also says to add its IP addresses to your allowlist, so the connection can reach the bucket.
There are now two ways to authenticate to S3:
- Access key and secret: the “programmatic username” and “programmatic password” for AWS, stored in the connector. This is how I set it up in my videos.
- Identity provider based: an IAM role in your AWS account that Data 360 is allowed to use, with an external ID that Salesforce generates for the trust policy. No long-lived keys are stored in the connector.
If your security team has a policy against long-lived access keys, the second option is the one to bring them.
Separate the concerns
Section titled “Separate the concerns”There’s a second benefit. You can separate your concerns: have your sysadmins who have the credentials set up the connection, and have your data people who are doing the data mappings pick the connection.
Salesforce builds that split in. To create a connection, its setup page asks for the “System Admin profile or Data Cloud Architect permission set.” The person mapping the pilots file doesn’t need the AWS secret, and shouldn’t have it. They need to see a connector called something like “Pilots bucket” in a list, and choose it.
That’s a design decision, so make it on purpose: who creates connectors, who may use them, and who rotates the secret when it changes.
One per environment
Section titled “One per environment”There’s a catch, and it shows up at deployment. When you go to building and deploying Data 360, the connection has to be pre-existing. It contains the actual credentials for reaching into the target system, so it isn’t moved for you. You set it up, potentially manually, in every one of your Data 360 environments: development, testing, production. A BigQuery key, for example, has to be applied again in each one.
Plan for it the way you’d plan named credentials in a core release: a list of connectors per environment, who sets each one up, and a check that they exist before anything that depends on them is deployed. Chapter 22 covers deployment.
Hundreds of doors, the same idea
Section titled “Hundreds of doors, the same idea”S3 is one connector of many. Salesforce’s architects describe “over 270 connectors, APIs, SDKs, and MuleSoft” for external sources: Salesforce’s own clouds, other applications, databases and warehouses, cloud storage, event streams and unstructured sources. Each one works the same way: a connection set up once, holding the credentials, picked by the streams that use it.
For the most sensitive sources there’s one more option, Private Connect. On AWS it uses AWS PrivateLink, and Salesforce describes the result as “private IP addressing, non-public routing, and zero internet exposure.” If a source must never be reached over the public internet, that’s the question to raise early, because it changes how the network is set up on both sides.
Watch it on video
Section titled “Watch it on video”In 2024 I filmed the day the S3 connector arrived, and why I liked it. And in 2026 I filmed a connection to Google BigQuery, with a service account as the integration user and a key to apply in every environment. The notes under the videos say what’s still right and what’s changed since.
What an architect decides here
Section titled “What an architect decides here”- Who creates connectors and holds the secrets, and who only picks them.
- How each connector authenticates: stored keys, or an identity provider and a role.
- The list of connectors for each environment, and who sets them up before a deployment.
- Which sources need Private Connect instead of the public internet.
Explore
Section titled “Explore”All checked 2026-11-14.
- Set Up Amazon S3 Connection (opens in a new tab), Salesforce Developers: permissions, the two ways to authenticate, the allowlist.
- Data 360 Architecture (opens in a new tab), Salesforce Architects: connectors and Private Connect.