feat: gateway v2

[sheensantoscapadngan]

Description 📣

This PR implements completely new gateway architecture for a more simplified and extendible networking model. Existing gateways will continue to function as usual because this is fully backwards-compatible

Related PR:
Infisical/cli#12

Type ✨

• Bug fix
• New feature
• Improvement
• Breaking change
• Documentation

Tests 🛠️

# Here's some code block to paste some code snippets

---

• I have read the contributing guide, agreed and acknowledged the code of conduct. 📝

[maidul98]

🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

[greptile-apps]

Greptile Summary

This PR introduces Gateway v2, a comprehensive next-generation infrastructure for managing secure proxy connections and certificate authorities in Infisical. The implementation adds a dual-gateway architecture that supports both the legacy Gateway v1 and new Gateway v2 systems simultaneously, enabling gradual migration without breaking existing functionality.

Key architectural changes include:

Database Schema Evolution: Five new tables are introduced - instance_proxy_config, org_proxy_config, org_gateway_config_v2, proxies, and gateways_v2. These tables manage hierarchical PKI and SSH certificate authorities at both instance and organization levels, with extensive encrypted storage for certificates, private keys, and certificate chains.

Proxy Service Architecture: A comprehensive proxy service manages certificate hierarchies with Root CA, Organization CA, Instance CA, Client CA, and Server CA structures. The service handles proxy registration, credential generation, and maintains separate certificate chains for different proxy types (instance vs organization proxies).

Gateway v2 Service: The new gateway service provides platform connection details through getPlatformConnectionDetailsByGatewayId, establishing dual-stage TLS connections (first to proxy relay, then mTLS to gateway through proxy). This replaces the relay-based approach of v1 with a more sophisticated proxy-based architecture.

API Integration: New REST endpoints are added under /api/v2/gateways for gateway management (register, heartbeat, list, delete) and /api/v1/proxies for proxy registration. The proxy registration includes custom authentication using PROXY_AUTH_SECRET for instance-level proxies.

Service Integration: Gateway v2 support is integrated across the entire application stack including dynamic secret providers, Kubernetes authentication, secret sync operations, secret rotation, and app connections. All services now accept both gatewayService and gatewayV2Service parameters, implementing a fallback pattern where v2 is attempted first before falling back to v1.

Frontend Support: New React hooks and API integration for Gateway v2 management, with unified gateway listing that combines both v1 and v2 gateways using an isV1 flag for differentiation.

Migration Strategy: The implementation maintains complete backward compatibility by supporting both gateway versions simultaneously. Existing v1 gateways continue to function while new v2 gateways can be deployed, allowing for zero-downtime migration.

Confidence score: 2/5

• This PR introduces significant security risks due to improper input validation and potential attack vectors in critical infrastructure code
• Score lowered due to DNS injection vulnerabilities, hardcoded security values, authentication bypass issues, and inconsistent type safety
• Pay close attention to gateway-v2.ts, proxy authentication logic, and certificate handling code

Context used:

Rule - # Greptile Code Review Prompt: OR Query Safety Check (knex.js)

Objective

Flag database queries that use or conditions without proper grouping, which can break outer filters and cause unintended data exposure.

What to Flag

Look for query builder patterns where or methods are called directly on the main query object without being wrapped in a subquery or callback function.

Flag these patterns:

• .orWhere(), .orWhereRaw(), .orWhereILike(), .orWhereIn(), etc. called directly on the main query
• Multiple chained or conditions without proper grouping
• Any or condition that could bypass security filters or WHERE clauses applied elsewhere

Examples to FLAG:

// ❌ DANGEROUS - or conditions break outer filters
query.where('status', 'active')
  .orWhere('name', 'like', '%search%')
  .orWhere('email', 'like', '%search%');

// ❌ DANGEROUS - mixed with other conditions
query.where('tenantId', userId)
  .where('deleted_at', null)
  .orWhere('name', 'like', '%search%')
  .orWhereRaw('email ilike ?', ['%search%']);

What NOT to Flag

Do NOT flag or conditions that are properly grouped within a callback function or subquery.

Examples that are SAFE:

// ✅ SAFE - or conditions grouped in callback
query.where('status', 'active')
  .where((qb) => {
    qb.where('name', 'like', '%search%')
      .orWhere('email', 'like', '%search%');
  });

// ✅ SAFE - explicit subquery grouping
query.where('tenantId', userId)
  .where('deleted_at', null)
  .where(function() {
    this.orWhere('name', 'like', '%search%')
        .orWhere('email', 'like', '%search%');
  });

Detection Pattern

Flag any line containing:

• .orWhere*() methods called directly on a query object
• NOT preceded by .where(( or .where(function
• NOT inside a callback function block

Review Message Template

When flagging, use this message:

⚠️ **Unsafe OR Query Detected**

This query uses `or` conditions directly on the main query object, which can bypass outer filters and security constraints.

**Issue:** OR conditions at the query root level can break tenant isolation, permission checks, or other important filters.

**Fix:** Wrap OR conditions in a grouped WHERE clause:
```javascript
// Instead of this:
query.where('important_filter', value)
  .orWhere('field1', condition)
  .orWhere('field2', condition);

// Do this:
query.where('important_filter', value)
  .where((qb) => {
    qb.where('field1', condition)
      .orWhere('field2', condition);
  });

Security Impact: High - Could expose unauthorized data

## Additional Context
This pattern is particularly dangerous in multi-tenant applications, permission systems, or any query with security-critical WHERE clauses. Always ensure OR conditions are logically grouped to maintain the integrity of outer security filters. ([link](https://app.greptile.com/review/custom-context?memory=c4ca0367-148d-42b9-bcbd-958caf88aa07))

<sub>54 files reviewed, 22 comments</sub>

<sub>[Edit Code Review Bot Settings](https://app.greptile.com/review/github) | [Greptile](https://greptile.com?utm_source=greptile_expert&utm_medium=github&utm_campaign=code_reviews&utm_content=infisical_4462)</sub>

[akhilmhdh]

Starting application level testing now!

[akhilmhdh]

Application testing