Why Using Feature Flags Is Compliant and Secure

If you’re familiar with feature flags, then you already know they have a ton of benefits for stakeholders all across your product delivery organization. We’re not going to cover all of that in this post. Instead, we’re going to look at a common hiccup some teams have when adopting feature flags, as well as how Harness Feature Flags was built to solve this problem. If you are new to Feature Flags, we do recommend reading our introduction to feature flags.

So, what’s this common problem we’re discussing? People who are worried about your application’s performance and security, of course. Always getting in the way! And for good measure, of course. Feature flags run in your code, they can be seen as a serious dependency, and even a risk. As such, from the moment we started building Feature Flags here at Harness, we took that seriously. We aimed for zero impact, zero upstream dependency, and zero risk to your application.

Why Are Some People Concerned About Feature Flags?

So, why can feature flags be seen as risky? A few reasons:

• They run in your code.
• They have to communicate to an external service to get configuration changes.
• The user experience depends on flags resolving.
• They can handle important data.

These are serious concerns that shouldn’t be downplayed, so let’s take a look at how we address them.

Architecting for Resiliency 

The way that Harness Feature Flags work is pretty simple:

1. You install either a client or a server SDK in your application.
2. You create flags in Harness.
3. The rules you set for the flags are communicated to the SDK via either pushing or pulling events.
4. The SDKs cache the rule sets to avoid constant communication with Harness. 

The first thing folks want to know is what happens if Harness goes down? Will my application fail to resolve? It’s important to know that when instantiating a flag in your code, you provide a default value in the code (see our docs on your specific SDK’s language to see how).

This default value is always present, so if the SDK can’t reach Harness and also has no cache, the SDK will still have an answer on what to evaluate. This means that Harness is never an upstream dependency for your application.

The next common question this workflow brings up is around performance. What is the impact of all the communication back and forth with Harness? Surely there is some lag there that can impact my application performance.

The good news is that because of the local SDK caches, the only communication to Harness comes when flag rules are updated. These server-sent events take only hundreds of milliseconds, and beyond that, you will have no latency caused by feature flag evaluation.

The result is an application architecture that you can trust to never degrade, slow down, or be a potential availability dependency for your application. You can learn more in our Feature Flag docs.

Architecting for Privacy

That covers resilience, but another common ask is around security. Since the SDKs are running in your application and rely on information you send to target your flags, how safe is your application’s information?

The way Harness Feature Flags work is:

• You send custom attributes to Harness when you instantiate the SDKs. These are things like emails, locations, plans - anything you want to evaluate flags against.
• In Harness, you then build rules against these attributes, such as “turn a flag on for all users in Texas” if “State” is an attribute you are sending us.

Because of this design, it’s important to note that Harness never has access to any information that you don’t give us. If you don’t want us to know it, we don’t. The Harness SDKs do not collect or communicate back to Harness any information that you do not explicitly pass into the SDK. We strongly suggest masking sensitive information with an abstraction on your side to keep all PII out of Harness.

Summary

At the end of the day, trust is one of the most important things when evaluating a vendor for tools like Feature Flags and CI/CD. We understand the importance of making a secure and compliant product. We built Harness Feature Flags to minimize what you need to trust, deferring to privacy and resilience as a default in all cases.

You can find more information in our documentation, as always. We’ve also written a post on the most common security questions regarding feature flags. This may put your mind at ease as well.

Happy reading!