2

In our organisation we use the Google Kubernetes Engine (GKE) to implement a micro-service architecture. As we are also G-Suite users, everyone in the organisation is guaranteed to have a Google account. In consequence we would like to use those accounts to manage authentication and authorization of micro services.

We have prototyped login using the angularfire2 client to authenticate against the Google Identity Platform. We also have Google Cloud Endpoints configured to control access to relevant services.

The piece we are missing is how to get from the identity in Google to an access token we can use on our services -- the access token coming back using the Firebase API has no claims in it, and the documentation on custom claims seems to make it quite clear that these go into the identity token.

My expectation would be to have JWTs with the appropriate audience (our backend), containing a sufficient set of claims to implement role based access control within the services. Ideally the infrastructure could validate a claim already -- some of our services are small enough to require only one role, which could be enforced outside the service. Or we could annotate our endpoints (Protobuf) with the required claims.

In the GCP environment, what is the standard process of creating access tokens to be used for accessing GKE services? Is there anything that supports this?

John Hanley
  • 74,467
  • 6
  • 95
  • 159
Peter Becker
  • 8,795
  • 7
  • 41
  • 64

2 Answers2

0

The piece we are missing is how to get from the identity in Google to an access token we can use on our services -- the access token coming back using the Firebase API has no claims in it, and the documentation on custom claims seems to make it quite clear that these go into the identity token.

Google OAuth Access Tokens do not have an identity in the sense that you want to use it. Identity is stored in the Identity Token. Add the scope "email" when authenticating the user. Google will return an ID Token. For some frameworks, you can request custom claims for the Identity Token.

In the GCP environment, what is the standard process of creating access tokens to be used for accessing GKE services? Is there anything that supports this?

There are two types of access excluding methods such as API keys. User Accounts and Service Accounts. Service-to-service typically uses service account Access Tokens (RBAC) or service account Identity Tokens (IBAC). In your case, you want to use Identity Platform which means User Accounts.

If I was designing this system, I would use User Accounts to authenticate with the system - Firebase is great for this purpose. I would look up what roles this identity supports/allows from my database (Firestore) and create a service account Access Token with the required scopes for GCP services. I would then use this Access Token for GCP service-to-service authorization. If I also required custom roles for my own services, I would create a custom Identity Token with my custom roles and include that as a custom HTTP header and include the Google Access Token in the standard HTTP "authorization: bearer" header. I would use the service account private key to sign my custom Identity Token or use a GCP IAM API to sign for me so that the other end can verify with the service account's public key. This method prevents data leakage at the client, no private keys are distributed, scopes/roles are not disclosed, etc.

John Hanley
  • 74,467
  • 6
  • 95
  • 159
  • Thanks for the detailed answer, John -- but I had gotten that far already. Our services do not need to know the identity, they just need to know a role was assigned in a trusted way, which is where the access token would come in. This seems to be consistent with what Google does on its services (e.g. Drive), but there seems to be no support for doing this in GKE. Right now we use a custom authorization service to map a Firebase ID token to our custom access tokens, and now explore replacing ESP with Envoy to get more control there. I was hoping to get more support from GCP. – Peter Becker Jul 06 '19 at 00:42
-2

I would suggest you follow this doc of authentication between services by using service account files.

Wayne Zhang
  • 147
  • 4
  • Hi Wayne. We use the service accounts for service to service authentication, but as far as I know nothing in there authenticates or authorizes a user. Am I missing something? We need to know which person is using the web client. – Peter Becker Jun 27 '19 at 08:32
  • If your web client can generate a JWT token with user_id, Endpoints proxy (ESP) will verify it and pass the JWT payload in the header x-endpoint-api-userinfo to your application to do the authorization. – Wayne Zhang Jun 28 '19 at 17:01
  • I don't see how we could generate a JWT in the client without leaking the private key. At the moment we use a custom service to take the Firebase ID token, validate it's issuer, then generate an access token of our own, which ESP should be trusting (that's my job for tomorrow). It still doesn't give us RBAC, but we can enforce that within the services. I was hoping for something along the lines of what Istio and Keycloak offer, which would be less work and less custom code to trust. – Peter Becker Jul 03 '19 at 11:49