AWS Secrets Manager Reviews

In my recent company, we use AWS Secrets Manager for all the applications where we store app-based, app-level secrets. We store all our secrets there. Currently, I'm working with AWS Secrets Manager and all encryption resources. In my company, we are using these secrets for the backend GoLang application. With the help of secrets stored in AWS Secrets Manager, the application fetches the secrets and works accordingly.

AWS Secrets Manager is similar to a vault in our homes where we store important things. We encrypt those items and store them in AWS Secrets Manager so we don't have to carry them around or keep them somewhere unsafe. All the secrets are encrypted and stored in AWS Secrets Manager. The functionality involves taking the secrets and decrypting them, or if not encrypted, using them as they are.

For all applications and resources such as database, MongoDB, Postgres, and everything which needs a username and password, it will be in AWS Secrets Manager. The code is structured to fetch from AWS Secrets Manager so it should not look anywhere else. It's the only place where we keep those important items.

The encryption capabilities of AWS Secrets Manager, where we use KMS (Key Management Store), which is an encryption key for AWS resources, are impressive. With KMS, we can encrypt our AWS Secrets Manager. Without access to KMS or AWS Secrets Manager, a person cannot access those items. KMS serves as a key to the vault. The integration between KMS and AWS Secrets Manager is quite astonishing.

We can specify permissions for AWS Secrets Manager through IAM roles and permissions. We can specify independent IAM permissions in AWS Secrets Manager, which is a significant advantage.

AWS Secrets Manager has a retention policy where we can specify how long a secret should exist. There is also version control, so if the secret is updated or values are changed, the secret receives its version. Similar to GitHub and Version Control Systems, we have versions in the secret to track changes and enable rollbacks.

AWS Secrets Manager plays a significant role in optimizing IT infrastructure security and efficiency. It serves an essential purpose because every application, website, or online activity requires authentication credentials. For API usage, an API key is needed. If values don't need to change frequently (static values), they become eligible for AWS Secrets Manager. By keeping everything in one place, the safekeeping of secrets remains under admin control. Without specific IAM permissions or access, nobody can access these secrets. This solves approximately 99% of the problems companies face with secret management.

When creating AWS Secrets Manager, it should be automated using tools such as Terraform, Puppet, or Ansible. With Terraform code, you specify the encryption key, secret name, rotation policy, and secret replication. Human error occurs when feeding secret values manually, especially with large amounts of secrets to input.

Secrets should never be protected only by IAM. They should be protected by multiple layers, such as IAM and one or two KMS keys. Additional security measures could be beneficial if necessary. The rotation policy is crucial because some secrets may become obsolete, require updates, or get compromised. With a weekly rotation policy, if unauthorized access occurs, the exposure is limited to seven days. The rotation policy can be customized according to needs.

I have been working with AWS Secrets Manager for approximately two years.

AWS Secrets Manager was easy to use because it comes integrated with the AWS infrastructure setup. We didn't need to look for alternatives.

AWS Secrets Manager is quite stable as we haven't faced any service-related issues. The issues we encountered were related to developer or configuration problems. The service performs well overall. Any updates or improvements to the resource would be beneficial.

I haven't encountered limit exceeded errors yet, though I'm uncertain about the secret key and value limits. We maintain a substantial number of secrets. When limit exceeded errors occur, it could become problematic since we don't have control over the secrets. As applications and companies grow, the number of secrets increases accordingly.

We can directly edit and feed values in plain text, mentioning the secret key and value in JSON format. This eliminates the need for manual UI input. We can code all secret keys and values and paste them, though this code must remain restricted.

We experienced minimal issues with secrets, but once in production, we encountered a problem where values weren't being fetched from a key. We contacted AWS support and waited approximately an hour for assistance. The issue turned out to be a coding error with incorrect value input. While an hour might not seem significant, in production environments where applications cannot experience downtime, it can impact company operations. I would rate technical support as eight out of ten.

Regarding customer support, we implemented blue-green deployment for zero downtime. When constructing zero-downtime solutions, infrastructure-related downtime becomes problematic. We experienced some challenges before getting back on track.

Positive

Before AWS Secrets Manager, we used Terraform Vault for our Terraform infrastructure. Terraform Vault serves a similar purpose for secret keeping but is specifically used for Terraform purposes rather than application level management.

The initial stages of AWS Secrets Manager were implemented using Terraform. All configurations visible in the AWS Secrets Manager UI were applied through Terraform. We focused on automating the entire infrastructure to minimize human errors.

To establish the basic structure, I needed to set up the Terraform infrastructure. We weren't authorized to feed values directly into the secret key-value pairs. While direct input would have been simpler, we had to manually add values to prevent secret leakage, as Terraform code resides in repositories with potential access risks.

AWS Secrets Manager, being an AWS resource, operates simply using access keys and secret keys. For third-party applications in our organization, we utilize access keys and secret keys from a user or create dedicated users. When creating an IAM user for secrets, we obtain the access key and secret key, providing necessary permissions following the least privileges principle.

A basic security audit involves controlling access to specific secrets for particular users. When writing policies, we specify AWS Secrets Manager and the exact secret using the resource ARN in the IAM permission JSON code. This ensures users can only access designated resources.

CloudTrail enables tracking user actions, including deletions and updates. It provides various filters for dates, time, users, and user groups, making it feasible to monitor AWS console activities. CloudTrail serves as an effective audit tool for administrators.

This review rates AWS Secrets Manager as 9 out of 10.

My main use case for AWS Secrets Manager is while deploying auto-scaling and different applications on AWS, where I store username and critical data on Secrets.

I use AWS Secrets Manager for a better way to manage different keys and rotate those keys at a fixed time interval, depending on the environment. In a production environment, I have to rotate the keys on a weekly basis, and for dev and stage environments, I rotate the key around a month, two months, or three months, as per the company policy.

The best features AWS Secrets Manager offers for me include the ability to publish my user's critical data including secret keys, passwords, or API URLs which I don't want to show to everyone. When required, it's called, and they can access it, and it's revoked, providing short-term access.

AWS Secrets Manager has impacted my organization positively through security improvements because on that basis, I can rotate my keys and passwords at a certain time.

I haven't felt any issues while using AWS Secrets Manager that would suggest areas for improvement.

I have been familiar with AWS Secrets Manager for around five or more years.

If you are considering AWS Secrets Manager, I advise that if you are deploying some application or any product tool on an AWS environment, you must store critical data including client passwords, client secrets, API URLs, or other critical data on AWS Secrets Manager for a better way to manage and securely use this type of data. I rate this product a 10.

My main use case for AWS Secrets Manager is to store all our passwords in the secret manager, which serves as a specific example of how I use it. AWS Secrets Manager fits into our workflows by helping us manage and rotate our sensitive information such as API keys and database credentials.

The best features AWS Secrets Manager offers include API key and Auth tokens, which it securely stores and we can use in our workflows. I also appreciate the zero-downtime updates and customizability.

For non-native servers, third-party API keys, or SSH keys, I can use a Lambda function to define exactly how rotation should happen, and I find these features the most valuable. AWS Secrets Manager has positively impacted our organization because I noticed it reduced our risk.

AWS Secrets Manager could not be better because there has been no frustration with the product.

I have been familiar with AWS Secrets Manager for three years.

I would rate AWS Secrets Manager a nine out of ten because we can use it for on-premises or multi-cloud access, API key and Auth tokens for securely storing, and database credentials, managing and automatically rotating the user password for RDS or Aurora cluster. I also appreciate this integration with Lambda functions so that it retrieves and caches secrets locally and reduces the API calls. I would recommend everyone to use AWS Secrets Manager for their security and for storing their passwords, because I see that passwords nowadays are easily compromised.

Positive

I use it for handling any confidential tasks or operations within my systems. 
Typically, we rely on the AWS Identity and Access Management center to set specific rules. In most cases, systems autonomously manage the secrets. While there are admins who can handle secrets from the console, we aim to minimize such instances.

AWS Secrets Manager has streamlined our processes for managing secrets and their lifecycle. We typically handle everything through automation, following a predefined approach. When we undertake our developments, we seamlessly integrate the process into our workflows. Essentially, our secrets require minimal intervention; they are automatically managed by the system itself. This ensures smooth operations without the need for manual intervention.

We integrate this tool with various AWS services, utilizing AWS Secrets Manager specifically for AWS resources. Any application, service, or deployment within AWS leverages Secrets Manager whenever it requires access to it.

There is room for improvement in terms of integrating with certain other platforms.

I have been working with it for approximately one year.

It has proven to be stable, as we have never experienced any interruptions.

It is sufficiently scalable to meet our requirements.

We have a solid relationship with technical support, finding them to be highly professional and responsive. I would rate them nine out of ten.

Positive

The initial setup was straightforward. Integrating with other services was straightforward, especially within the AWS environment.

The cost is somewhat high.

It's a solid product, especially if you're already working within the Amazon ecosystem. Overall, I would rate it seven out of ten.

I use AWS Secrets Manager to securely store and manage sensitive information with automatic encryption.

AWS Secrets Manager has improved my application's security by securely storing and automatically rotating sensitive information like passwords.

The most valuable feature of AWS Secrets Manager is its seamless integration with various AWS services.

An area for improvement in AWS Secrets Manager could be expanding integration options beyond AWS services. Enhancing compatibility with other platforms like Azure and providing more automated options for secret rotation could simplify the overall integration process for users.

I have been working with AWS Secrets Manager for six months.

I have not had any stability issues with the solution.

AWS Secrets Manager is quite scalable.

Before using AWS Secrets Manager, I worked with Azure Key Vault. I switched to Secrets Manager primarily for its seamless integration with AWS services and its automated secret rotation capability.

The initial installation is very simple. It only takes a few minutes to deploy the solution.

AWS Secrets Manager is reasonably priced, especially for applications with occasional secret retrieval. However, costs can escalate with frequent use, particularly for large-scale data operations, so it is essential to consider usage patterns when evaluating expenses.

For those considering AWS Secrets Manager, I recommend leveraging its secure and easy-to-use features for storing and managing secrets. Since AWS doesn't have a direct alternative, it is a solid choice for enhancing security in applications. Before starting, ensure a clear understanding of your application's secret management needs to make the most of this tool. 

We use the solution to host secret credentials. It helps us orchestrate our platform and the customer's environment.

We can utilize the solution directly through the access feature in the certificate. Thus, we don't have to maintain or create another vault for ourselves. It brings more speed and flexibility to the development team.

The solution's price is getting higher. It could be improved.

The solution is very stable. I rate its stability a ten out of ten.

The solution is very scalable. I rate its scalability a ten out of ten.

The solution's initial setup is complex. I rate the process a five out of ten.

We don't need to manage or update or maintain the solution. Also, we don't have to be responsible for monitoring or backup. From the perspective of the code, we plug the application into it, and we are good to go.

The solution's cost is complicated. I rate its pricing an eight out of ten.

It is a good product; I rate it a nine out of ten.

AWS Secrets Manager is used for storing secret information that has to be a secret from your customer and your employees. They would need your credentials. When you use a Google service for something, you have to log in using your credentials, even when you are accessing it programmatically. You cannot include these things in the program because programs are stored outside our community in some repository or version control system like GitHub. So you cannot add these credentials in the code because it is public. For that, we store it in AWS Secrets Manager, and whoever writes the program connects with the solution to fetch the authentication information. Even the person who writes the program doesn't need to know the guarded secret.

Even though I said that the employee or programmer doesn't need to see the secret, he can view the secret if he intends to. He just has to display the value he fetched from the AWS Secrets Manager.

The solution should add one more layer of encoding and decoding so that when the programmer fetches the value from the AWS Secrets Manager, what he receives is only an encoded version. Instead of directly sending it to Google, he sends the authentication information to another AWS service which decodes it and then sends it to Google. If you add one more layer of security to AWS Secrets Manager, even the programmer will not be able to see the secrets.

We have been using AWS Secrets Manager for more than one year.

AWS Secrets Manager is a stable solution.

AWS Secrets Manager is a scalable solution. Around four people use the solution in our organization.

AWS Secrets Manager’s initial setup is very easy.

I recommend users use AWS Secrets Manager because it's a good way to store secrets. When you create a secret in AWS Secrets Manager, you have to protect it with a key. You have two options. You can either use the key supplied by AWS or create your own key. If you create a key of your own, every program using this secret has to be whitelisted in another AWS service called the Key Management Service (KMS). But you don't need to do that if you use the default key supplied by AWS. Users should watch out for that when they use AWS Secrets Manager.

Overall, I rate AWS Secrets Manager ten out of ten.

We store all our sensitive data in Secrets Manager.

Secrets Manager helps in retrieving the enrollment variables used by the code. We also find AWS Glue useful for ETL processes along with AWS EMR for its Spark engine.

Security Manager is itself a feature. It doesn't have sub-features. I also like AWS Glue, which is used for ETL purposes.

There is a potential improvement in connecting AWS Secrets Manager to Jenkins CI/CD pipeline to automatically reflect changes in production.

We have been using AWS Secrets Manager for six years.

I encountered bugs with package alignment and service downtime that caused stability issues.

I have not contacted Amazon support, but I believe they may be helpful in solving problems.

Positive

The initial setup is not complex. It's a straightforward process once you define the particular configuration.

The product seems affordable in the Bahrain region, which we have chosen over Mumbai for cost efficiency.

I recommend Secrets Manager as a very good tool.

AWS Secrets Manager takes care of managing the secret within AWS and other AWS services. 

With AWS Secrets Manager, we can configure the required secrets in the secret manager, and we can access that from the Lambda service without any additional effort.

So, we just have to update policies. Based on that policy, we automatically allow the Lambda service to access the response secret manager.

The most valuable feature is security. 

There is room for improvement in the pricing model.

In future releases, I would like to see a feature. For example, other secret managers don't allow the use of services other than AWS service. So, if we have AWS Secrets Manager allowed to a user outside the AWS environment, it will be an additional feature.

I have been using this solution for two years. 

I would rate the stability a ten out of ten. 

The framework itself takes care of itself. So, I would rate the scalability a nine out of ten.

I personally refer to the documentation.

Positive

It was easy to deploy. The usage and creation are simple.

I would recommend using the solution. It is a good solution if you are in an AWS environment. 

Overall, I would rate the solution a ten out of ten.