PKI-146 Add RBAC policy conditions for certificate metadata

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

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

Greptile Summary

This PR extends certificate RBAC by adding metadata as a permission condition for certificates, allowing fine-grained access control based on certificate metadata key/value pairs. It also consistently updates altNames handling from a comma-separated string to a proper array across all permission subject calls.

Key changes and findings:

• Information disclosure in getCertificateRequest: The certificate request fetch was moved before the permission check (needed to obtain metadata for RBAC). This allows unauthorized users to distinguish non-existent requests (404) from ones they lack access to (403) by probing UUIDs. Consider adding a general permission guard before the DB fetch.
• Permissive metadata condition schema: The outer .partial() on the metadata condition in CertificateConditionSchema makes the $ELEMENTMATCH operator optional, meaning metadata: {} is a valid (and potentially permissive) condition. Removing the outer .partial() would enforce the element-match operator when the metadata key is present.
• Dual API calls in CertificateCertModal: useGetCertBody is now always fetched as a fallback even when the user already has ReadPrivateKey permission and bundleData resolves successfully — resulting in an extra redundant request for users with full access.
• Single key/value condition limitation: The ConditionsFields deduplication logic limits users to one metadataKey and one metadataValue condition per rule. Multi-key matching (e.g., env=prod AND team=infra) is not expressible through the UI and is worth documenting.
• The double permission check in certificate-v3-service.ts (current metadata → new metadata on edit) is a correct approach to prevent privilege escalation.

Confidence Score: 3/5

• Mergeable with caution — the information disclosure in getCertificateRequest and the permissive metadata condition schema should be addressed before broad rollout.
• The core RBAC logic is sound and the frontend/backend types are kept in sync, but the reordering of the DB fetch before the permission check in getCertificateRequest introduces a resource-existence information disclosure. The outer .partial() on the metadata condition schema is a subtle security concern that could allow an empty-condition bypass. These are not critical blockers but warrant fixes before the feature is widely used.
• backend/src/services/certificate-request/certificate-request-service.ts (auth ordering) and backend/src/ee/services/permission/project-permission.ts (metadata condition schema) need the most attention.

Important Files Changed

_{Last reviewed commit: 5d4cfca}

@greptile re-review this PR

@greptile

1. We had to flip the order because to check the permissions, we need the metadata from the certificate object. It is not easy to enumerate over UUIDs.
2. I think the solution we have handles it pretty nicely and does not need any change
3. This is how condition fields work.
4. We do similar things for other entities as well.

Fair points on 2-4. If this follows existing patterns across the codebase, that makes sense.

On point 1 though: While UUID enumeration is indeed hard, the information disclosure concern isn't about brute-forcing UUIDs — it's about what happens when someone does have a valid UUID (from logs, URLs, error messages, etc.). The original ordering prevented distinguishing "doesn't exist" from "you can't access it," which is a deliberate security pattern.

If you need metadata for RBAC and this reordering is unavoidable, consider the two-stage check I suggested: a lightweight permission guard before the fetch (general Certificates subject), then the full metadata-enriched check after. That way you get the metadata you need without leaking existence info to unauthorized users.

But if this pattern is already used for other entities and you've assessed the risk, I'll defer to that architectural decision.