Service Account-Based Authentication for Legacy Applications in GCP

Migrating your workloads from On premises to Google Cloud Platform (GCP)? It’s a big move, and security is a top priority. In this blog, we’ll break down how to keep your apps and databases talking to each other safely during a lift and shift migration. We get it — you might be on a tight deadline, or dealing with a high-traffic application. We’ll look at the options that make the most sense for your situation where you don’t want to make any code changes and want to replicate as is working from on premises to GCP. So you can keep things running smoothly. Let’s get started!

Use Case : No Code authentication for lift and Shift workloads

Customer Requirements for Migrating On-Premises Workloads to GCP:

• Rapid Migration: The customer needs to migrate their on-premises workloads to GCP quickly.
• No Code Changes: The migration solution must not require any modifications to the existing application code.
• Strict Deadlines: The customer has strict deadlines for completing the migration to the desired future state.
• High-Traffic, Real-Time Applications: The applications involved are characterized by high traffic and real-time communication patterns.
• High Throughput: The solution must support high throughput to accommodate the application traffic.
• No Additional Latency: The solution should not introduce any additional latency, so hops between systems must be minimized.
• Unified Solution: A single solution should be used for all application-to-application communication.
• Application-Level Authentication: The customer requires authentication at the application level due to concerns about control within the Shared VPC environment.

Authentication Options for Application-to-Application/Database Communication

Several options exist for securing application-to-application/database authentication, each with its own benefits and drawbacks. Some may necessitate code modifications, the introduction of new tools, or the establishment of standard operating procedures.

Available Options:

Service Accounts: Assign service accounts to all applications within a VM (grouping similar applications). Implement firewall rules to permit ingress connections between VMs associated with these service accounts. This is a recommended practice for L3 authentication.

• Pros: No application code changes required. Easy to implement. Communication between Managed Instance Groups (MIGs) is already encrypted.
• Cons: Requires coordination with the central team responsible for managing firewall policies.

Allow Host Authentication from Request Header: Modify the application to validate the calling host name and grant access based on configuration. For Walmart’s home-grown framework, consider creating and adding a request interceptor component to the application.

• Pros: Minimal application code changes and GCP configuration adjustments. Relatively quick implementation.
• Cons: Application must undergo a change implementation, testing, and release process.

OAuth 2 Tokens: Create a GCP IAM principle and credentials. Assign IAM roles to applications. The caller application fetches tokens for each call, and other applications validate these tokens by calling IAM. This is a best practice for L7 authentication.

• Pros: Individual service-level authentication using access tokens. Secure and managed.
• Cons: Requires major code changes. Overhead associated with managing tokens (fetching and validating).

Kubernetes & Service Mesh: Host applications on container pods and utilize a service mesh (like Istio) to manage traffic flows and access policies.

• Pros: Provides a uniform layer for implementing security measures (encryption, authentication, authorization), ensuring secure inter-service communication without burdening individual services.
• Cons: Requires significant application upgrades for Kubernetes deployment and team readiness. Best suited as a modernization track solution.

Proxy VM: Introduce a proxy VM or Docker container with an Envoy app to route ingress/egress traffic, handling certificate onloading/offloading. This can be achieved using Application Load Balancers.

• Pros: Sidecar pattern for certificate validation. No code changes needed in main application components.
• Cons: Introduces latency, which can be critical for revenue-generating transactions. Requires team proficiency with containerization approach for future onboarding.

Apigee: Create APIs and backends as instances. This approach offers modernization potential but demands significant changes to the microservices architecture, impacting inter-service communication and authentication/authorization mechanisms.

• Pros: Enterprise-level, consistent service management across the platform. Enables CI/CD.
• Cons: Time-consuming, requires higher-level direction for adoption, and introduces overhead.

The optimal authentication method depends on your specific requirements, existing infrastructure, and long-term goals. Considering factors like the level of security needed, the complexity of implementation, and the impact on application performance with customers we came to the conclusion of using service account based authentication.

Implementing Service Account based filtering

The proposal to employ service accounts for authentication at layer 3 offers a practical and seamless approach, especially in scenarios involving “lift and shift” migrations. It aligns with the current authentication practices employed for applications hosted on Rackspace.

Key Advantages:

• Simplicity: This approach does not necessitate any modifications to the application code, as it relies solely on service accounts for authentication. This eliminates the need for complex code changes or API integrations, which can be time-consuming and error-prone.
• Security: Service accounts provide a secure and managed identity solution for applications running in Google Cloud. They offer granular access control and can be easily revoked or rotated, enhancing the overall security posture.
• Scalability: Service accounts can be easily managed at scale, making them suitable for large-scale deployments. They can be created, deleted, and modified programmatically, enabling seamless integration with automated deployment and management processes.

As shown in the diagram, Lets look into the steps to allow connection between App1 to App2 and App2 to DB.

Implementation Steps:

Create an Instance Template with a Service Account:

• Create an instance template that specifies the desired operating system, machine type, and other instance properties.
• Associate a service account with the instance template. This service account will be used for authenticating connections between instances.

Create an Instance Group Using the Instance Template:

• Create an instance group using the instance template created in step 1.
• All instances launched within this instance group will inherit the service account specified in the instance template.

Create a Firewall Rule to Allow Ingress Connections:

• Configure a firewall rule to allow ingress connections from the source service account to the destination service account.
• This rule ensures that instances within the instance group can communicate securely with each other and with other resources within the VPC network.

Example:

• Let’s consider a scenario where we need to establish communication between two instance groups, “mig-instance-group” and “mig-instance-group-2.” This communication should be at the application-to-application level.
• Furthermore, we need to enable communication between “mig-instance-group-2” and “mariadb-instance-group.” This communication should facilitate interaction between the application and the database.

The firewall rules are not configured using IP addresses.

Additional Considerations:

• Firewall Policies: Firewall policies can be further refined by utilizing security tags. This provides more granular control over network traffic and can be used to restrict access to specific ports or IP addresses.
• Scalability and Automation: Service accounts can be easily managed at scale using automation tools such as Terraform or Cloud Deployment Manager. This enables efficient provisioning and management of instances and firewall rules, particularly in large-scale deployments.
• Monitoring and Logging: It is essential to monitor and log all authentication-related activities to ensure security and compliance. This can be achieved by setting up audit logs and utilizing monitoring tools to track authentication attempts and failures.

https://cloud.google.com/iam/docs/service-account-monitoring