feat(creative-studio): deployed Creative Studio to a dedicated project on GCP

[khangnguyen-ds-ti]

Summary

Adds a persistent red warning banner to Creative Studio’s authenticated frontend experience.

The banner informs trial users that the application is a trial environment and that they must not enter, upload, or generate sensitive, confidential, or personal information.

Motivation

Creative Studio is currently running as an internal, time-boxed trial. Users need a clear and consistent reminder that the environment is not appropriate for sensitive data before they use generation, upload, or other application features.

Change

• Adds a red, accessible warning banner to the root Angular application shell.

• Displays the following message:

  Trial environment: Do not enter, upload, or generate sensitive, confidential, or personal information.
  

• Shows the banner on authenticated Creative Studio routes, including admin routes.

• Excludes login, password-reset, and support-ticket routes, which do not render the standard application shell.

Deployment Details

Project: iconic-ds-creative-studio-dev
Frontend: https://iconic-ds-creative-studio-dev.web.app

The frontend was deployed through the existing Cloud Build and Firebase Hosting workflow.

Test Plan

• Confirmed the banner branch source was synced to Cloud Shell before validation and deployment.
• npm run compile: passed.
• npm run lint: passed with 0 errors.
  • The repository retains 335 pre-existing lint warnings outside the scope of this change.
• git diff --check: passed.
• Confirmed the frontend Cloud Build and Firebase Hosting deployment completed successfully.
• Manually verified the deployed application displays the red warning banner above the standard application header.

Follow-up Work

Security remediation — priority

• Immediately verify whether /api/workflows-executor/* can be reached without authenticated application-level identity and invoke Vertex AI. If confirmed, require authentication and authorization before execution, then add rate limits, per-user quotas, spend budgets, and alerting.
• Immediately remove raw Authorization header logging from the workflow executor. Review the affected log retention/access scope and rotate or revoke credentials/sessions as advised by Security.
• Verify whether /api/workbench/render is externally reachable without authentication. If confirmed, require authenticated authorization and restrict source media to application-owned, authorized gs:// objects or an explicit allowlist. Do not fetch arbitrary caller-provided URLs.
• Configure and enforce IDENTITY_PLATFORM_ALLOWED_ORGS for approved internal domains/groups. Verify the live Identity Platform provider configuration and reject unapproved identities before just-in-time user provisioning.
• Correct the production CORS configuration mismatch between FRONTEND_URL and Terraform-provided CORS_ORIGINS, then test the deployed allowlist.
• Replace project-level roles/storage.objectAdmin on the backend runtime service account with bucket-scoped, least-privilege permissions.
• Add browser hardening headers: CSP, X-Content-Type-Options, referrer policy, and permissions policy.

Access architecture

• Assess replacing Firebase Hosting with a private frontend deployment behind an external HTTPS load balancer and IAP.
• Note: Firebase Hosting cannot simply be placed behind IAP as a protected origin. Achieving IAP enforcement requires hosting the frontend behind infrastructure that supports IAP, such as Cloud Run behind an external Application Load Balancer using a serverless NEG, with backend access aligned to the same perimeter.
• Confirm that direct Cloud Run URLs and alternate hosting paths cannot bypass the chosen access boundary.

Trial operations

• Define a teardown date and execute the documented teardown when the trial ends.
• Formalize the Cloud Run Job seeding path in Terraform/bootstrap.
• Update PRIVATE_SQL_DEPLOYMENT.md with the active Cloud Build connection name and seeding procedure.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.