gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-05 20:40:18 -08:00
Code Issues Packages Projects Releases Wiki Activity

GITBOOK-734: No subject

Browse Source
This commit is contained in:
SirBroccoli
2024-12-19 16:10:32 +00:00
committed by gitbook-bot
parent 299fe36f36
commit fd78deddd6
1 changed files with 22 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
pentesting-ci-cd/serverless.com-security.md
View File

@@ -554,21 +554,33 @@ Overly permissive IAM roles can grant unauthorized access to cloud resources, le
### **Insecure Secrets and Configuration Management**
Storing sensitive information (e.g., API keys, database credentials) directly in `serverless.yml` or code can lead to exposure if repositories are compromised or if access to AWS is compromised as they will be readable from the lambdas configurations.
Storing sensitive information (e.g., API keys, database credentials) directly in **`serverless.yml`** or code can lead to exposure if repositories are compromised.
The **recommended** way to store environment variables in **`serverless.yml`** file from serverless.com (at the time of this writing) is to use the `ssm` or `s3` providers, which allows to get the **environment values from these sources at deployment time** and **configure** the **lambdas** environment variables with the **text clear of the values**!
{% hint style="danger" %}
Therefore, anyone with permissions to read the lambdas configuration inside AWS will be able to **access all these environment variables in clear text!**
{% endhint %}
For example, the following example will use SSM to get an environment variable:
```yaml
provider:
environment:
DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true}
```
And even if this prevents hardcoding the environment variable value in the **`serverless.yml`** file, the value will be obtained at deployment time and will be **added in clear text inside the lambda environment variable**.
{% hint style="success" %}
The recommended way to store environment variables using serveless.com would be to **store it in a AWS secret** and just store the secret name in the environment variable and the **lambda code should gather it**.
{% endhint %}
#### **Mitigation Strategies**
* **Environment Variables:** Inject secrets at runtime without hardcoding.
```yaml
provider:
environment:
DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true}
```
* **Secrets Manager Integration:** Use services like **AWS Secrets Manager**, **Azure Key Vault**, or **HashiCorp Vault**.
* **Secrets Manager Integration:** Use services like **AWS Secrets Manager.**
* **Encrypted Variables:** Leverage Serverless Framework’s encryption features for sensitive data.
* **Access Controls:** Restrict access to secrets based on roles.
* **Avoid Logging Secrets:** Ensure that secrets are not exposed in logs or error messages.
***