Secrets
Integrations
Yupdates reads and writes to many external systems, often in the context of your accounts. Doing that securely is a top priority.
-
Delegation
-
Services like GitHub allow you to delegate certain rights to third-party applications, usually using OAuth grants.
We will always look to integrate this way if it's available. It allows you to scope down access to only the few permissions that Yupdates needs and allows you to revoke access without key rotation or any participation from our systems.
-
Secrets
-
Some integrations do not offer delegation and need you to supply a credential, and we have a robust system for storing and isolating them. To learn more, see the next section.
Secret isolation
This gets a bit in the weeds, but we want to make sure it's clear. If you're left with any questions, please contact us.
-
1. No delegation?
-
When a service we integrate with doesn't offer a way to delegate permissions to third-party applications, you need to supply a credential to Yupdates if you want to use that integration.
If you choose to activate an integration that requires a credential, you should always supply one with the least permissions possible. For example, if it's a read-only integration, obtain a read-only key from the service in question.
-
2. KMS
-
When you configure a secret, it is immediately encrypted using the AWS Key Management Service (KMS).
That's the last time our internet-facing API nodes will ever see the raw value because they only have permission to encrypt secrets - never to decrypt them.
-
3. Data keys
-
We're not sending the secret directly into KMS. KMS itself will never see the raw value.
Instead, KMS creates a unique 'data key' per secret. We encrypt the incoming secret with this data key, and store the encrypted version of that data key alongside the encrypted material.
This is called envelope encryption, and there's a good video on this technique here.
-
4. KMS Permissions
-
To get precise: our internet-facing service has the kms:GenerateDataKey permission, and that's it. It stores the encrypted materials in DynamoDB, and it sends that to the async system when a job needs to be done.
The async system is the only entity with the kms:Decrypt permission. That system has no state and runs on a separate, isolated network. It receives a job assignment via a secure SQS queue, does the work, and sends back the results on a separate queue.
-
5. Dedicated accounts
-
And there is more than one async system; each is run with an independent set of accounts, the strongest AWS isolation paradigm.
The isolated async system with `kms:Decrypt` permissions for dedicated integrations is only used for those dedicated integrations. The isolated async system that has permission to POST with webhook credentials is only used for posting to webhooks. RSS/Atom polling happens on yet another isolated system that has no access at all.
-
6. Tying it all together
-
In the diagram below, you can see each aspect of this system put together.
Your secret arrives, and it's immediately encrypted. The encrypted materials are stored in the context of your account. When work needs to be done, the scheduler sends a job assignment over a secure SQS queue. The assignment and encrypted materials arrive at the stateless worker. The secret is decrypted via KMS, the work is completed, and everything is discarded.
More topics
See the security section of our FAQ page to learn more.