hi there,
I’m connecting to an external API and am wondering if there is a part of liberty for encrypted credential storage/management?
Thanks,
Peter
Hi Peter,
Using Variables we can store credentials reasonably securely.
Create a new Variable under the Data Store menu in Build
Give it an appropriate name, such as xyz key or token etc.
Within the Value field enter a comment to the effect that the value is configurable within the API Admin Area.
Set the Variable as being Editable in Application
Now Save.
In the variables list, the value will always show with the default value you have just set. However, if you now create an Admin page for Key Management somewhere within your admin interface you can add the Variable and Special Record Editor Widget to your new page.
Once in your page you can select which variables you want to manage within the widget.
You can then secure the page as you wish.
Additionally you could use the Hidden Text with Reveal presenter from Appshare to obfuscate the entry and only allow for its replacement within that interface.
Hope this helps.
Adam
Ok Adam thanks and are the keys/secrets encrypted in storage by default in liberty create?
Hi Peter,
Not at the moment, but plans are underway to make this happen.
If you would like to support the idea which is currently under review, or would like to add any individual context or requests, please follow the link below:
Idea (netcall.com)
Adam
Hi Adam, just been notified of this in progress. My LM has asked me if you could send over a risk assessment of this and why it wasn’t actioned sooner? He is concerned about how you perceived the risks and how you mitigated against these- as when googled or asking Chat GPT, or stack overflow, they mention the importance of encrypting API keys. Thanks, Peter
Good Afternoon Peter,
Sorry, to be clear, all data is encrypted at rest using AWS EBS. Amazon EBS encrypts your disk volume with a data key using industry-standard AES-256 data encryption.
Within the platform, our standard connectors, including OAuth in the generic REST adapter, the SAML connector, and our Google AI tools, have always handled keys securely. These keys are obfuscated and stored appropriately, allowing them to be entered but never retrieved.
In addition any data held in data objects, with the appropriate data group selected, will be encrypted in the database as well – further details can be found here: https://docs.netcall.com/docs/liberty-create/2024.2/build-studio/security-1/encryption
The keys we’re discussing are used within a more generic API context where values are submitted in headers or payload bodies that optionally can be text, numbers, or keys. Access to these keys has always been restricted to build administrators only. Additionally, there’s a flag for credentials used in headers to prevent them from appearing in logs.
For Create v24.3 (October) we plan to improve this further, allowing variables to be flagged as credentials that will see them stored and treated in the way described above.
Thanks, Adam.
1 Like
Thanks for the response Adam. The EBS encrypted volumes is AWS standard and not particular to the API keys though, but I had read the earlier replies as saying it was not encrypted at storage so that is better than I was fearing. If it is using the default keys there would still be a vulnerability from the netcall side in that this could then mean anyone at netcall could potentially see or access our keys. Are you using a customer managed key with IAM policies for who can internally access our unencrypted data? Does anyone at Netcall have build admin access to see our API keys for example? And does this mean that there is not additional encryption of the API keys beyond the EBS default for keys used via the variables pathway? As in order to use an authorisation header route, there doesn’t appear to be an option here for using an encrypted at point of access key, as a developer I can either enter a key as text or reference a variable. So the credentials tag here will protect it from logs, does it also ensure the above treatment of the key? It would be good if there was a hint description of what the credential toggle does in the UI so developers know what they gain or risk by enabling or not enabling it.
So there’s the above aspect but just to clarify for the October release, in the liberty front end it will be encrypted so that the keys can’t be directly seen within the platform without specific least privilege permission? Will there be a special section of the variables list with greater protection, or will it be an addition secrets management platform like in AWS?
Thanks again,
Peter
Hi Peter,
Responding on behalf of Adam as he’s wrapped up prepping for an upcoming demo.
Access to your data and applications is managed by policy with full auditability. As Liberty is provided as a managed service we need access for the purpose of support and maintenance but this is only granted as needed, to employees of appropriate seniority. This is primarily our IT team and/or support team when you log support requests. For support that’s typically to build/test environments only unless by agreement with the customer.
Additional encryption of the API keys is specifically what the new feature will introduce. It will allow a credential stored in a variable to be marked as such and stored encrypted in the database itself, over and above the encrypted EBS volume.
Encryption will follow the standards used in the ‘stronger’ definition, highlighted in the link to the data groups section within the docs portal above. The full spec for the change is being finalised but we’ll take into account your comments regarding hint descriptions. Control over what’s shown within the platform, to what user roles, will be within the control of the builder of the solution.
Richard
2 Likes
Thanks Richard appreciated!
Hi Adam is there any update on the progress of the credentials management capability? We want to be able to securely make API calls from liberty create at some point. Thanks, peter