Service Accounts & API Keys
Service accounts are used for programmatic access to the features for an application through FeatureHub SDKs.
A service account will need a minimum of
READ access to an environment in order to access a feature value. You can set permissions for a service account from the FeatureHub Admin Console.
When a service account is given access for an environment for a selected application, it automatically creates two types of API keys that you can choose from Client Evaluated API Key and Server Evaluated API Key. Read more info on API Keys types here
The same service account can be used across multiple environments and applications. We recommend two service accounts be created for an application, one with access to a production environment and the other one for test environments. However, FeatureHub remains flexible to how customers could split their service accounts according to individual needs.
In case an API key gets compromised there is an option to reset the key and immediately disable the previous one.
|Because API Keys are based on a service account ID, it is not possible to reset a single API key at a time, but there is an option to reset service account ID, which in turn will cause reset to all API keys attached to that service account. This could potentially affect multiple applications and multiple environments. Thus, it is recommended to always have a separate Service Account for a production environment. There is also an option to either reset Client evaluated API keys or Server evaluated API keys. Warning is provided before the reset. The option to reset the keys will only be available to Portfolio Admins and Super Admins, since service accounts settings can only be viewed by them. Only Portfolio and Super admins always have full permissions to see in which apps and environments a service account is used.
For each application environment, there are permissions you can assign to service accounts.
READRead the value of a feature
LOCKCan lock a feature, so its value can’t be changed, this gives us a safety net when deploying incomplete code into production. (Typically developers and testers keep features locked until they are finished and ready to be set)
UNLOCKCan unlock a feature, so it’s value can be changed
CHANGE_VALUECan change the value of a feature or can "retire" a feature
CHANGE_VALUE permission supersedes the