Security

Security is a primary consideration when moving systems into production. In this section we'll dive into how Inngest handles security, including endpoint security, encryption, standard practices, and how to add SAML authentication to your account.

Signing keys and SDK security

Firstly, it's important to understand that in production all communication between Inngest and your servers is encrypted via TLS. The SDK also actively mitigates attacks by use of the signing key, a secret pre-shared key unique to each environment. By default, the signing key adds the following:

  • Authentication: requests to your endpoint are authenticated, ensuring that they originate from Inngest. Inngest SDKs reject all requests that are not authenticated with the signing key.
  • Replay attack prevention: requests are signed with a timestamp embedded, and old requests are rejected, even if the requests are authenticated correctly.

It's important that the signing key is kept secret. If your signing key is exposed, it puts the security of your endpoints at risk. Note that it's possible to rotate signing keys with zero downtime.

Function registration + handshake

Functions are defined and served on your own infrastructure using one of our SDKs. In order to run your functions, they must be synced, or registered, with your Inngest account. This is required for Inngest to know which functions your application is serving and the configuration of each function. Syncing functions is done via a secure handshake. Here's how the handshake works:

  1. After your SDK's endpoint is live, a PUT request to the endpoint initiates a secure handshake with the Inngest servers.
  2. The SDK sends function configuration to Inngest's API, with the signing key as a bearer token.
  3. The SDK idempotently updates your apps and functions. If there are no changes, nothing happens.

This process is necessary for several reasons, largely as serverless environments are the lowest common denominator. Serverless environments have no default bootup/init process, which means serverless environments can't self-initiate the sync. Secondly, serverless platforms such as AWS Lambda and Vercel create unique URLs for each function deployed, which can't be known ahead of time. The incoming PUT request allows the SDK to introspect the request's URL, which is then used for all function calls.

Note that because the SDK only sends HTTP requests to api.inngest.com to complete the sync, it never leaks the signing key to clients attempting registration, keeping your key secure.

End to end encryption

Inngest runs functions automatically, based off of event data that you send to Inngest. Additionally, Inngest runs steps transactionally, and stores the output of each step.run within function state. This may contain regulated, sensitive data.

If you process sensitive data, we strongly recommend, and sometimes require, end-to-end encryption enabled in our SDKs. End-to-end encryption is middleware which intercepts requests, responses, and SDK logic on your own servers. With end to end encryption, data is encrypted on your servers with a key that only you have access to. The following applies:

  • All data in event.data.encrypted is encrypted before it leaves your servers. Inngest can never read data in this object.
  • All step output and function output is encrypted before it leaves your servers. Inngest only receives the encrypted values, and can never read this data. Function state is sent fully encrypted to the SDKs. The SDKs decrypt data on your servers and then resume as usual.

With this enabled, even in the case of unexpected issues your data is encrypted and secure. This greatly improves the security posture for sensitive data.

Security practices, audits, and reports

Inngest is regularly audited to adhere to standards such as SOC2 Type II, and applies best practices internally to mitigate security risks. We take security seriously, and also undergo routine pentesting and red-team simulated attacks. For more information on our security practices, reach out to security@inngest.com.

SAML

Enterprise users can enable SAML authentication to access their account. In order to enable SAML, you must:

  1. Reach out to your account manager and request a SAML integration.
  2. From there, we'll request configuration related to your SAML provider. This differs depending on your provider, and may include:
    1. A metadata URL; an SSO URL; An IdP entity ID; an IdP x.509 certificate, and so on.
  3. Your account manager will then send you the ACS and Metadata URL used to configure your account.
  4. Your account manager will work with you to correctly map attributes to ensure fully functioning sign in.

It's important to note that once SAML is enabled, users must sign in via SAML. If you're not on an enterprise plan, reach out to hello@inngest.com and we'll get you set up. There is no additional charge for SAML authentication below 200 users.