Add Health Check Endpoint#101
Conversation
Wiz Scan Summary
To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension. |
Yash Shrivastava (alephys26)
changed the title
![wiz-55ccc8b716[bot]](https://avatars.githubusercontent.com/u/11163827?s=60&v=4){kind=small}
| RoleArn: clusterCtx.RoleARN, | ||
| RoleSessionName: aws.String("heimdall-health"), | ||
| }) | ||
| return err |
There was a problem hiding this comment.
How is this checking Spark logically? Can't we do something like, run a basic select 1?
There was a problem hiding this comment.
It will run too long and then the check will be failing for load balancers etcetra.
It is fine for v1 to remain as it is, in next iterations we can try and see other ways that are better.
| } | ||
| } | ||
|
|
||
| req, err := http.NewRequestWithContext(ctx, http.MethodGet, clusterCtx.Endpoint+"/v1/info", nil) |
There was a problem hiding this comment.
Here Also, is it complex to add a small select 1, because it is more bulletproof way of saying Trino is up and running and executing queries.
There was a problem hiding this comment.
Added count of activeWorkers as check, to not use the queue slot for querying.
There was a problem hiding this comment.
When we run this healthcheck on Blue instance, it won't any activeWorker right? My thought was to test the path with which the end user is coming in, then its a better way to say cluster is working. I was just thinking by keeping the status page also in mind, like i am going to use this as source of truth for Our StatusPage.
| } | ||
| defer db.Close() | ||
|
|
||
| rows, err := db.QueryContext(ctx, fmt.Sprintf("SHOW WAREHOUSES LIKE '%s'", clusterCtx.Warehouse)) |
There was a problem hiding this comment.
SQL Injection in Go Database Queries Using database/sql Package (CWE-89)
More Details
This rule detects potential SQL injection vulnerabilities in Go code that uses the database/sql package. SQL injection occurs when user-supplied data is improperly sanitized and included in SQL queries, allowing an attacker to execute arbitrary SQL commands.
| Attribute | Value |
|---|---|
| Impact |  |
| Likelihood |  |
Remediation
SQL injection is a technique where malicious SQL statements are inserted into application entry points, allowing attackers to view, modify or delete data in the application's database. This vulnerability can lead to unauthorized data access, data loss, and in some cases, complete system compromise.
To remediate this issue, use parameterized queries or prepared statements instead of string concatenation when constructing SQL queries. Parameterized queries separate the query logic from the user input, preventing the input from being interpreted as part of the SQL statement. This effectively eliminates the risk of SQL injection.
Code examples
// VULNERABLE CODE - User input is concatenated directly into the SQL query
query := "SELECT * FROM users WHERE name = '" + userName + "'"
rows, err := db.Query(query)// SECURE CODE - Using parameterized queries with placeholders
query := "SELECT * FROM users WHERE name = ?"
rows, err := db.Query(query, userName)Additional recommendations
- Follow the principle of least privilege and grant minimal database permissions to the application.
- Implement input validation and sanitization for all user-supplied data.
- Use the latest version of the database driver and keep it up-to-date with security patches.
- Adhere to the OWASP Top 10 and CWE guidelines for secure coding practices.
- Consider using an Object-Relational Mapping (ORM) library, which can help prevent SQL injection by automatically parameterizing queries.
- Implement centralized logging and monitoring to detect and respond to potential attacks.
Rule ID: WS-I013-GO-00041
| o.Credentials = credentials.NewStaticCredentialsProvider( | ||
| *out.Credentials.AccessKeyId, | ||
| *out.Credentials.SecretAccessKey, | ||
| *out.Credentials.SessionToken, | ||
| ) |
There was a problem hiding this comment.
Hardcoded AWS Credentials in Go Application
More Details
Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.
Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.
| Attribute | Value |
|---|---|
| Impact |  |
| Likelihood | |
Remediation
Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.
To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.
Code examples
// VULNERABLE CODE - Hardcoded AWS credentials
import (
"github.com/aws/aws-sdk-go-v2/aws"
"github.com/aws/aws-sdk-go-v2/credentials"
)
creds := credentials.NewStaticCredentialsProvider(
"AKIAIOSFODNN7EXAMPLE",
"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"",
)// SECURE CODE - Using AWS credential provider
import (
"github.com/aws/aws-sdk-go-v2/config"
)
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
// Handle error
}
// AWS credentials are retrieved securely from the environment or other sourcesAdditional recommendations
- Follow the AWS best practices for managing AWS access keys and secret access keys.
- Implement least privilege access principles by granting only the necessary permissions to AWS resources.
- Regularly rotate AWS credentials and revoke unused or compromised credentials.
- Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
- Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).
Rule ID: WS-GO-00051
| github.com/aws/aws-sdk-go-v2/config v1.30.3 | ||
| github.com/aws/aws-sdk-go-v2/credentials v1.18.3 | ||
| github.com/aws/aws-sdk-go-v2/feature/s3/manager v1.18.3 | ||
| github.com/aws/aws-sdk-go-v2/service/cloudwatchlogs v1.58.7 |
There was a problem hiding this comment.
The following vulnerability impacts github.com/aws/aws-sdk-go-v2/service/cloudwatchlogs versions <1.65.0: GHSA-xmrv-pmrh-hhx2.
It can be remediated by updating to version 1.65.0 or higher.
| github.com/aws/aws-sdk-go-v2/service/cloudwatchlogs v1.58.7 | |
| github.com/aws/aws-sdk-go-v2/service/cloudwatchlogs v1.65.0 |
Background
We did not have health checks for the clusters in Heimdall. Introducing health check endpoints for greater observability. The health checks are set on clusters (with opt-in) and run only if there is at least a single command that uses the cluster.
Changes
Cluster Health Check System
local.yaml. [1] [2]Plugin Health Check Implementations
HealthCheckmethods in ClickHouse, DynamoDB, ECS Fargate, Glue, Ping, Postgres, Shell, and Snowflake plugins for backend connectivity probing. [1] [2] [3] [4] [5] [6] [7] [8]Documentation and Configuration
README.mdto document cluster health checks, endpoints, configuration, and plugin support. [1] [2] [3]sparkeks,postgres).Dependency Updates
go.modfor compatibility with health check implementations. [1] [2]Tests
Tested with go test files. All unit tests passed.
Also tested locally with docker compose.