CODEWITHSUNDEEP
azureencryptionaws-secrets-manager
Luke
Luke

Reputation: 344

secrets vaults: how to encrypt clientId and clientSecret in a web app?

People say not to store API Keys and passwords config files and instead to use a Secrets vault. eg. AWS or Azure.

But to access these you need a clientId and clientSecret. These need to be stored somewhere on the app. eg app.config. So I really don't understand what problem this solves if the hacker can use the clientId and clientSecret in the app the get the passwords or api keys anyway?

it seems even worse than the original problem storing one api key, since if they get access to the secrets manager they will have ALL THE KEYS and ALL the passwords.

Upvotes: 1

Views: 1375

Answers (3)

gusto2
gusto2

Reputation: 12085

But to access these you need a clientId and clientSecret. These need to be stored somewhere on the app. eg app.config

You can use runtime permissions to access the secrets and parameters. In Azure it is called Managed Identities, in AWS there are service roles. I am more familiar with AWS, so I will use its terminology, but every larger cloud provider has similar approach with different names.

Basically you can assign the compute resource where your code runs (EC2/VM server, Lambda function, ECS container,...) a role - you can consider it as set of permissions. Using AWS API you can access the secrets or parameters from the code without storing any client credentials.

if they get access to the secrets manager they will have ALL THE KEYS and ALL the passwords.

That's why we all need to use principle of the least privileges, the defined runtime identity should have only permissions it really needs.

Upvotes: 0

Gaurav Mantri
Gaurav Mantri

Reputation: 136346

If you are using Azure, the answer is to use Managed Identities.

The way it works is that you assign an identity to the resources (VMs, WebApps etc.) that need access to Key Vault. That way the resource becomes like a user in your Azure AD (much like a Service Principal or any other user). Then you can make use of Key Vault Access Policies to assign appropriate access to keys and secrets in your Key Vault to these Managed Identities. Doing this would not require you to specify a Client Id/Client Secret to access the Key Vault.

While the Managed Identity is something you assign to a resource, it could become cumbersome if you have many resources. That's where User Assigned Managed Identity comes into picture. A User Assigned Managed Identity is a resource in your Azure Subscription. The process is very much similar: you create such identity and then assign appropriate access to this identity on your Key Vault resources.

Now wherever you need to access Key Vault in your applications, you will specify the id of this identity. The application using appropriate SDK will get an access token on behalf of this identity and connect to Key Vault using that access token.

You can learn more about these identities here: https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview.

Upvotes: 0

Amith Jayasekara
Amith Jayasekara

Reputation: 439

AWS offers few different services to store your secrets. Let's say if you have a database password in an application configuration file, you can use either AWS Secret manager or AWS Parameter store to store them as secret.

To retrieve these values securely, you do not have to store another secret stored in your application. You can use a mechanism called role-based access in AWS.

If you running your application on an ec2 instance, you can configure an AWS role/profile and assign it to the ec2 instance which is linking the secret manager and the ec2 machine securely and your application has connectivity to decrypt the secret and use it inside the application.

Upvotes: 0

Related Questions