1
0
mirror of https://github.com/Unleash/unleash.git synced 2025-09-05 17:53:12 +02:00

docs: add Edge section to security doc (#9562)

This commit is contained in:
Nnenna Ndukwe 2025-04-08 04:23:25 -04:00 committed by GitHub
parent e76d04a7ad
commit 494d5fd749
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 20 additions and 6 deletions

View File

@ -22,7 +22,7 @@ There are several steps to ensuring your feature flag implementation is audit-pr
## Introduction to regulatory compliance frameworks
Unleash is designed to support critical enterprise compliance standards. In this tutorial, we reference three frameworks that organizations in highly regulated industries are most likely to be audited against:
Unleash is designed to support critical enterprise compliance standards. In this guide, we reference three frameworks that organizations in highly regulated industries are most likely to be audited against:
[FedRAMP](/using-unleash/compliance/fedramp): A U.S. government program that standardizes how federal agencies assess, authorize, and monitor cloud services. For organizations listing their software on the [FedRAMP](https://www.fedramp.gov) marketplace, Unleash's security controls are designed to meet these rigorous requirements.
@ -140,7 +140,7 @@ Imagine a developer working at a large banking platform who wants to modify a fe
4. Final sign-off from technical leadership
With Unleash, you can create a change request workflow to reflect these exact requirements.
And from a security perspective, you'll always want an auditable trail of changes that occur in your feature flag system. We record all changes like these in the event logs. These are the configuration management practices required by compliance frameworks like SOC 2, FedRAMP, and ISO 27001. Well explore [event logs](#audit-manual-and-automated-events-in-unleash) more in a later section, but its important to note throughout this tutorial since its relevant to many features in Unleash that align with security and compliance standards.
And from a security perspective, you'll always want an auditable trail of changes that occur in your feature flag system. We record all changes like these in the event logs. These are the configuration management practices required by compliance frameworks like SOC 2, FedRAMP, and ISO 27001. Well explore [event logs](#audit-manual-and-automated-events-in-unleash) more in a later section, but its important to note throughout this guide since its relevant to many features in Unleash that align with security and compliance standards.
Projects in Unleash have an open [collaboration mode](/reference/project-collaboration-mode) by default, which means anyone with access to Unleash can see the project and submit change requests in it. However, only users with specific permissions can approve, apply, or skip them. None of the [predefined roles](/reference/rbac#predefined-roles) have any change request permissions, so you must create [custom project roles](/reference/rbac#predefined-roles). You can adjust the collaboration mode of your project to restrict visibility and limit who can submit change requests.
@ -193,7 +193,17 @@ This is a potential attack surface area that you wouldnt want to be the root
With Unleash, you can architect your feature flagging solution in a way that all user data stays within your applications. When using server-side SDKs, user data remains within your application and is never shared with the Unleash server regardless of your setup. For client-side SDKs, you can retain all user data within your applications by either [self-hosting Unleash](/understanding-unleash/proxy-hosting#you-host-everything), or [self-hosting Unleash Edge](/understanding-unleash/proxy-hosting#unleash-hosts-the-api-you-host-edge). Read more on the [Unleash architecture here](/understanding-unleash/unleash-overview).
The tutorial so far has focused on how you can use the features of Unleash to improve your application's security posture, making sure that feature flags are not the weak link. But what about Unleash itself, as a company and SaaS service? You might be asking…
### Use Unleash Edge for enterprise-grade data privacy
To take scalability, high availability, and resiliency to the next level for large enterprises, we built [Unleash Edge](/reference/unleash-edge)—a lightweight proxy layer that sits between your Unleash API and SDKs. Beyond the performance benefits, Unleash Edge delivers critical enhancements to both security and privacy.
Deployed within your own infrastructure, Edge ensures that PII and sensitive context data never leave your network, [regardless of which SDKs you use](/understanding-unleash/unleash-overview#unleash-sdks). Each Edge instance can be scoped to specific projects or environments, enforcing least privilege access and tight network segmentation.
With Edge, you can keep your core Unleash service hidden from the internet while evaluating feature flags at the edge for better performance and scalability. Unleash Enterprise Edge cannot access the [Unleash Admin API](/understanding-unleash/unleash-overview#admin-api), minimizing the impact of compromised clients or credentials. In our cloud-hosted offering, you can also define an [IP allow list](#set-up-ip-allow-lists-for-enhanced-security) for the Unleash instance and Hosted Edge to further reduce the attack surface.
For regulated environments that require continuous availability, you can configure persistent storage—such as Redis or local backup files—to keep feature flag evaluations running, even if the main Unleash server is temporarily unreachable. Learn more about Edge architecture and setup in our [Edge Concepts](/reference/unleash-edge/concepts).
The guide so far has focused on how you can use the features of Unleash to improve your application's security posture, making sure that feature flags are not the weak link. But what about Unleash itself, as a company and SaaS service? You might be asking…
## Can Unleash itself pass a security audit?
@ -207,7 +217,7 @@ When you engage with Unleash, you will get access to our Trust Center, which hou
## Best practices and recommendations
Throughout this tutorial, we've explored how to use Unleash Enterprise as a secure and compliant feature flag system. You now understand how Unleash's features work together to pass security audits while enabling your teams to build and ship safely.
Throughout this guide, we've explored how to use Unleash Enterprise as a secure and compliant feature flag system. You now understand how Unleash's features work together to pass security audits while enabling your teams to build and ship safely.
By using Unleash with security and compliance in mind, you've learned how to transform what could be a potential security liability into an asset that strengthens your overall security posture. Here are key recommendations to make sure your feature flag implementation meets enterprise security and compliance standards:

View File

@ -29,16 +29,20 @@ Unleash provides both [server-side](/reference/sdks#server-side-sdks) and [clien
#### Server-side SDKs
Server-side SDKs run in backend applications and retrieve feature flag configurations using the [Client API](#client-api) either from Unleash server or [Unleash Edge](#unleash-edge). Server-side SDKs cache all feature flag data in memory, applying activation strategies locally. This makes flag evaluation incredibly fast, as it is a simple function operating on local state, without the need to poll data from the database. This architecture results in a small delay (typically a few seconds, but configurable) when propagating configuration changes to your applications.
Server-side SDKs run in backend applications and retrieve feature flag configurations using the [Client API](#client-api) either from Unleash server or [Unleash Edge](#unleash-edge).
Server-side SDKs cache all feature flag data in memory, applying activation strategies locally. This makes flag evaluation incredibly fast, as it is a simple function operating on local state, without the need to poll data from the database. This architecture results in a small delay (typically a few seconds, but configurable) when propagating configuration changes to your applications.
Supported languages include: [Node.js](/reference/sdks/node), [Go](/reference/sdks/go), [Java](/reference/sdks/java), [Python](/reference/sdks/python), [.NET](/reference/sdks/dotnet), [PHP](/reference/sdks/php), and more.
#### Client-side SDKs
Client-side SDKs are used in frontend and mobile applications. They communicate with Unleash or [Unleash Edge](#unleash-edge) through the [Frontend API](#frontend-api). Supported platforms include: [JavaScript](/reference/sdks/javascript-browser), [React](/reference/sdks/react), [iOS](/reference/sdks/ios-proxy), [Android](/reference/sdks/android-proxy), and more.
Client-side SDKs are used in frontend and mobile applications. They communicate with Unleash or [Unleash Edge](#unleash-edge) through the [Frontend API](#frontend-api).
Unlike server-side SDKs, client-side SDKs do not perform the flag evaluation locally. Instead, they fetch all enabled feature flags for a given [Unleash Context](/reference/unleash-context). The flag evaluation happens inside [Unleash Edge](#unleash-edge), or within the Unleash server. Client-side SDKs cache evaluated feature flags in memory using a single evaluation call to the server, making flag evaluation secure, fast, and efficient.
Supported platforms include: [JavaScript](/reference/sdks/javascript-browser), [React](/reference/sdks/react), [iOS](/reference/sdks/ios-proxy), [Android](/reference/sdks/android-proxy), and more.
### Flag evaluation
The following table outlines where flag evaluation happens with different SDK setups.