Professional Cloud Developer
Pub/Sub is an asynchronous messaging service that decouples publishers from subscribers. Publishers send messages to a topic, and subscribers receive them through a subscription. This decoupling makes cloud-native applications more flexible and easier to scale. There are two subscription models: pull subscriptions, where the application actively asks for messages, and push subscriptions, where Pub/Sub delivers messages directly to a web endpoint via HTTP POST requests. For Cloud Run, push subscriptions are preferred because they allow the service to start up automatically when a new message arrives.
To connect Pub/Sub to Cloud Run, developers often use Eventarc to create a trigger that acts as an event receiver. The trigger listens for a specific action, such as a new message published to a topic. Key components include event filters, which define which messages trigger the service; a destination, which is the Cloud Run service; and a transport topic, which is the Pub/Sub topic where original messages are sent. Configuring these triggers ensures events are delivered in the standard CloudEvents format, making data handling consistent.
Managing the message lifecycle prevents data loss during processing failures. If a message cannot be delivered after several attempts, it can be sent to a dead-letter topic for later investigation. Developers can also use message attributes to provide extra context or filter data for the receiver. Implementing a retry policy with exponential backoff helps the system handle temporary network issues without losing information.
Security for push endpoints ensures only authorized services can trigger your application. Developers must enable authentication by associating a service account with the push subscription. This setup includes a JSON Web Token (JWT) in the request header to verify the sender’s identity. Properly granting IAM roles, such as Pub/Sub Publisher and Cloud Run Invoker, is necessary for the entire event-driven workflow to function securely.
To build a secure event-driven system, you must manage how services authenticate each other. Eventarc acts as a bridge connecting event providers to destinations like Cloud Run. Authentication ensures only trusted sources can trigger your application. Establishing a secure identity for your event receiver is the first step in protecting your cloud-native apps.
Specific IAM roles are required to allow events to flow correctly. The Cloud Run Invoker role allows a service account to call your application endpoint. Without this role, the system blocks the request and shows an authentication error. Other key roles include Eventarc Event Receiver, which lets the trigger receive events from providers, and Pub/Sub Publisher, which is required for sources like Cloud Storage.
A service account acts as the identity for your Eventarc trigger. By default, Google Cloud often uses the Compute Engine default service account, but using a custom service account is a best practice to follow the Principle of Least Privilege. This ensures each component has only the permissions it needs. When configuring a trigger, you must link it to a service account that has permission to invoke your Cloud Run service. This process uses OpenID Connect (OIDC) tokens to verify that the event source is legitimate. If the setup is incorrect, your service receives a message stating the request was not authenticated. Always verify that the service account has the correct token creator permissions if you are using older Pub/Sub configurations.
Managing these permissions correctly helps maintain a decoupled architecture, where services work independently while communicating through secure channels. Using tools like the Policy Simulator helps test changes to security settings before applying them. Regularly auditing these roles prevents unauthorized access and keeps event-driven workflows running smoothly.
Eventarc is a service that helps you build event-driven architectures by routing signals from different sources to specific destinations. When deploying to Cloud Run, you use an Eventarc trigger as a bridge that listens for changes and starts your service. This setup allows for decoupled communication, meaning your services do not need to be directly connected to work together.
To set up a trigger, you must define the trigger type, which can be a Google source, a Custom source, or a Third-party provider. You also select an event provider, such as Cloud Storage or Pub/Sub, and a specific event type that describes what happened. For example, you might trigger a process whenever a new file finishes uploading to a storage bucket.
Precise delivery is handled through filters, which are rules that match specific criteria to ensure only the right events reach your application. You should also pay attention to the region where your resources are located. Matching the trigger’s location with the source and destination helps minimize latency and improve performance.
Security is managed through service accounts that provide the necessary identity for the trigger to function. You must grant the Eventarc Event Receiver role to the trigger’s account so it can receive data from providers. Additionally, the Cloud Run Invoker role is required to allow the trigger to successfully call your service when an event occurs.
You can create these triggers using the Google Cloud console, the gcloud CLI, or Terraform. After creation, it is important to verify the trigger is active by listing your triggers in the console or command line. This ensures your event-driven application is ready to process real-time data. Common configuration steps include selecting the correct destination service, defining the service URL path, and enabling Retry on failure for better reliability.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts