Enforced provider and projectID in db call

[DharunMR]

Summary

This PR implements strict security boundaries for entity retrieval and property management by enforcing the Security Triple (EntityID, ProjectID, ProviderID) across the database and service layers.

Previously, certain database calls and service methods relied on incomplete identifiers, which theoretically could allow for cross-provider or cross-project data access if an ID was known. This refactor ensures that every entity-related operation is strictly bounded by both the project and the provider that owns the entity.

Key Changes:

• Database Layer (SQL)
  Enforced Constraints: Updated GetEntityByID, GetEntityByName, and DeleteEntity queries in entities.sql to require project_id and provider_id. Property Security: Updated property-related queries (GetProperty, GetAllPropertiesForEntity, DeleteProperty) to utilize JOIN or USING clauses against entity_instances, ensuring property operations cannot bypass entity ownership boundaries. Optimized Flush Cache: Updated ListFlushCache to join with entity_instances, allowing background workers to retrieve the provider_id directly from the database without extra Go-side lookups.

• Service Layer (Go)
  Property Service: Refactored EntityWithPropertiesByID and related methods to accept and validate the full Security Triple. Repository Service: Updated GetRepositoryById, GetRepositoryByName, and Delete methods to pass mandatory security parameters. EEA & Background Workers: Updated the Event Aggregator and reconcilers to use the ProviderID now provided by the enhanced flush cache queries.

• API & Middleware
  Controlplane: Updated API handlers (Artifacts, Repositories, Profiles) to translate provider names from the request context into UUIDs via providerStore.GetByName to satisfy the new database constraints.

• Fixes Enforce provider and project ID in GetEntityByID db call #4417

• Fixes Enforce provider and project ID in EntityWithProperties in the properties service #4419

Testing

• Test Suite

  Ran go test ./... (100% passing) to verify that the embedded database correctly respects the new project_id slices and that all handlers propagate context properly.

• Manual Verification

  • Spun up the local environment using make run-docker.
  • Executed a manual SQL injection test via docker exec -it postgres_container psql.
  • Created a mock project, provider, and entity instance.
  • Verified that querying the exact entity UUID using the authorized project_id array returned the entity (1 row).
  • Verified that simulating a cross-tenant IDOR attack by querying the exact entity UUID with an unauthorized/different project_id array correctly returned 0 rows (Access Denied).

[coveralls]

Coverage is 60.204% — DharunMR:Enforce-provider-and-projectID into mindersec:main. No base build found for mindersec:main.

[evankanderson]

It looks like you may also have a merge conflict, but this looks good other than a few small comments -- I'd like to avoid adding remote (serial) lookups in loop contexts -- I didn't look in enough detail to know for sure here if that was happening..

[evankanderson]

I think you just force-pushed to the wrong branch. :-/

[DharunMR]

I think you just force-pushed to the wrong branch. :-/

Unfortunatly! now solved it

[DharunMR]

@evankanderson i've verified the tests pass locally ,but fails ci

[evankanderson]

One small concern about duplicating getAuthorizedProjects logic twice, and some code that I think is functionally dead and should probably be removed.

[evankanderson]

Verified that this is only called by getEntityInner, which is only called by the strategies in handlers/strategies/entity for handling updates of resources which were auto-created due to parent resources.

[evankanderson]

(In response to the question whether this was called in a loop)

[DharunMR]

I had actually removed getAuthorizedProjects in my latest commit

[evankanderson]

(This has a merge conflict again, sorry!)

[DharunMR]

(This has a merge conflict again, sorry!)

resolved it now