A Guide on Proper Feature Flag Lifecycle Management and Secure Conduct

Photo Credit: FlyD on Unsplash

Feature flags need to be included in the shift-left strategy like any other software component to combat any vulnerabilities that open doors for cyber-exploitations. Feature flag security starts with a well-regulated feature flag lifecycle, starting from toggle configuration planning to toggle retirement.

Toggles are beneficial when used appropriately but detrimental when used inappropriately or used by malicious users. In this article, you will learn the bad habits you should avoid that make your feature flags insecure. To understand how to secure feature flags we will learn about the feature flag lifecycle and how to prevent misconfigurations during the lifecycle phases.

What are Bad Actions that Make Feature Flags Insecure?

Below are some of the bad habits you should avoid when handling feature flags:

1. Lack of access controls: If feature flags have the ability to switch off a feature then it is important to set control over who can access features. Some users have to be given the ability to read feature flags while others are given the ability to modify and operate feature flags. Losing control over feature flags is the same as losing control over your system. Not setting RBAC tools that authorize control over feature flags is detrimental. In the next section, you will learn how to set up RBAC in Unleash.
2. Inadequate authentication mechanisms: It is highly recommended to use third-party platforms for managing your feature flags. Feature flag platforms such as Unleash provide enough solutions to secure your features. However, failing to implement the security mechanisms puts your feature flags of being modified by unauthorised users. Multi-factor authentication has to be enabled.
3. Poor audit trails and infrequent audits: There are many feature flag management platforms being released every year. Some platforms have audit trail features while others don’t have them. It is important to ensure that your feature flag management platform has audit trail features. Unleash offers event logs that detail when a feature flag was created, modified, or deleted. Mostly it specifies the user that applied the changes. Event logs have to be reviewed from time to time to check for any abnormal behavior.
4. Neglecting secure default states: A feature toggle can either be on or off, it is very important to ensure that the default state of the feature toggle is safe. For example, if you design a feature that secures the network then it is crucial to ensure that the default state of the feature flag is on. Default states should never be ignored or neglected.

The biggest ramification caused by insecure flags is a security breach. If an unauthorized user gets access to modifying flags they have a lot of power. They can switch off many feature flags, roll back updated and new features, and turn off security mechanisms that are enabled by feature flags. These changes cause a lot of operational disruptions.

A security breach causes compliance violations that can lead your company to lose all security compliance certificates and badges achieved. Losing compliance certification causes reputational damage that decreases your client base.

Feature Flag Management Lifecycle

Following the feature flag lifecycle gives you an opportunity to configure every detail of the flag at every step. Below are the phases of the feature flag lifecycle phases:

1. Planning and Creation

This is the stage where you choose the best feature flag for your task and determine the feature flag’s life span. Feature flags are a part of your deployment, rollback, and CI/CD plan. Feature flags can be classified into two categories: short-lived and long-lived. Short-lived feature flags are used for a short period, usually from weeks to 3 months. Examples of short-lived feature flags are experiment and release flags. Long-lived feature flags are indefinite, they are used for years. Examples of long-lived feature flags are permission flags and operational feature flags.

Their creation and lifecycle planning is heavily dictated by when and how you want to deploy new features. Feature flags have different lifespans depending on their task. Below are different types of feature flags offered by the Unleash feature flag platform.

Unleash allows you to specify the lifetime of the feature flag using the Unleash platform UI. Pressing on the pen icon button shown in the image above enables you to specify the lifespan of the feature flag.

When you create a feature flag you have to state its lifespan. Long-lived feature flags have to be reviewed and modified from time to time to ensure that they give good results when the codebase changes. As for short-lived feature flags they have to be deleted when they are no longer in use since they are used in a very short period of time. Keeping expired feature flags has its own consequences. Expired feature flags can waste resources and increase cloud costs if they are responsible for activating resource usage.

It is important to follow naming conventions and feature flags when creating them. For example, a feature flag can have the global prefix to show it is accessible to everyone or have an RLS prefix to show it is a release feature flag.

2. Implementing and Deploying Feature flags

Integrating feature flags into your framework is the most critical stage of a feature flag. You have to follow coding best practices to ensure that the code does not have any technical debt. Sensitive data has to be encrypted and sanitized. This is the stage where you have to implement role-based access control to prevent unauthorized access.

It is very important to know the impact and damage the feature flag can cause when misused. This will also help you know who has to have access to using the feature flag. You can secure this feature flag phase by implementing RBAC. Unleash Pro allows you to create users and assign them different roles such as Editor, Viewer, and Admin. A user who has been given the viewer permission does not have the ability to edit feature flags.

You can also implement Unleash RBAC through API requests. The “rootRole”: 3 gives the user the viewer role, if you want to give the user the editor role you specify the root role as 2.

curl - location - request POST 'https://eu.app.unleash-hosted.com/eugg0002/api/admin/user-admin' \
 - header 'Authorization: INSERT_API_KEY' \
 - header 'Content-Type: application/json' \
 - data-raw '{
 "name": "Wame",
 "email": "username@email.net",
 "sendEmail": true,
 "rootRole": 3
}'

3. Testing

Before you deploy and activate the feature flag it is very important to stress test the different states of the feature flag. Does it do what it is designed to do when it is on? Does it cause any problems when it is off? After testing the flag, ensure that logs are being recorded. Logs detail all events a feature flag goes through and also who uses the feature flag.

Unleash has a playground that allows you to debug and test feature flag toggles.

5. Monitoring and Management

Regularly revising and reviewing feature flags’ event logs is crucial to ensure that feature flags are performing as expected. Feature flags have to be modified and fine-tuned using user feedback and performance data.

Granting user access through API tokens is beneficial because tokens have an expiry date, and you can control how long a user will have access to the feature flag API. Tokens are a fast way of authenticating users without asking for their credentials. Unleash enables you to grant users API tokens:

curl - location - request POST 'https://eu.app.unleash-hosted.com/eugg0002/api/admin/api-tokens' \
 - header 'Authorization: INSERT_API_KEY' \
 - header 'Content-Type: application/json' \
 - data-raw '{
 "username": "env-access",
 "type": "CLIENT",
 "environment": "development",
 "projects": [
 "*"
 ]
}'

7. Retirement

Once a feature flag has accomplished all its intended purposes it reaches its final stage, the retirement phase. In this phase, the feature flag integrated code is removed safely in a way that there are no components that depend on the feature flag. Keeping a feature flag longer than it should, introduces technical debt and vulnerability. It is easy to forget that a feature flag is not needed, this leads to no access controls not being set around it which opens the door for unauthorized users.

Conclusion

Attempting to secure a feature flag because there are rising vulnerabilities is inefficient and hard. This happens because of the technical debt that accumulates when you configure feature flags without securing them in the beginning.

Securing feature flags is easy when you implement security techniques such as RBAC when creating them. Feature flags aren’t meant to be a conundrum component of DevOps. Implementing feature flags is an easy task when creating them using a management platform. Unleash provides you with features that allow you to secure your feature flags such as RBAC, multi-factor authentication, and debugging solutions.