0
votes

Starting with this:

  • users have their own google user accounts that are setup locally via gcloud login
  • the application is using the gcp APIs in the usual way- by default it will look for GOOGLE_APPLICATION_CREDENTIALS, GCE roles, service accounts, or use the local users gcloud configured credentials
  • when users run it locally it will use their own user account, when run in gcp it will use a service account
  • The user's account also has access to impersonate the service account. So when running the app locally users first do gcloud config set auth/impersonate_service_account [SA_FULL_EMAIL] and it can be run with the same creds as what will run in the dev environment- without them having to download any keys

Now that works. BUT I also want to make it possible to run the applications locally in containers too. Using docker/docker-compose/minikube/etc how can I make it possible to impersonate a service account?

the container would need access to the gcloud creds and it would need to set impersonation in the session too before the app starts somehow. This must not be done in code- the app should just use the APIs as normal without having to do anything differently.

EDIT: when applications run in dev or prod GCP accounts/projects they run in the context of a service account that has correctly scoped permissions for that specific application. Developer's own user accounts have broad permissions to the dev environment. When running locally its useful to run with the same service account that application runs with in the dev environment instead of the developer's own user account

2
Edit your question with more details. 1) Are you using the CLI gcloud in the container? 2) If the users already have permissions, why do you want to impersonate a service account. 3) The CLI is used for development, for production environments the CLI credentials should not be used. Instead you should use a service account with the container. 4) If you need to use user credentials, during the authorization phase inside the container, capture the OAuth Access Token and use that for authorization to impersonate.John Hanley
5) Try restating your question with what you need and not what you think you need. Here I mean what is the authorization design? If users are accessing shared resources, user credentials are usually correct. If the user is logging into your web server and the service is accessing resources, then a service account is usually correct.John Hanley
feel like i was pretty clear. want to test running an application with the service account credentials when running locally, in a container, without having to generate a static key for that service account by impersonating itred888
If your question was clear, I would not have posted a five-part comment.John Hanley
i added to original questionred888

2 Answers

1
votes

The correct way to achieve this is the Secret Manager that is supplied by Google Cloud.

  • Activate Secret Manager API in your Google Cloud account.
  • Create Secret data and relevant payload either using GC UI or sdk.
  • Use the following function in your settings.py with your Project ID.
  • Give permissions for your service account to access Secrets (If it does not already have access)
  • Use the Secret Manager to access the payloads in your code without explicitly exposing the payload.
def access_secret_version(secret_id):
    """
    Access the payload for the given secret version if one exists. The version
    can be a version number as a string (e.g. "5") or an alias (e.g. "latest").
    """
    project_id = PROJECT_ID
    version_id = 1
    # Import the Secret Manager client library.
    from google.cloud import secretmanager_v1beta1 as secretmanager

    # Create the Secret Manager client.
    client = secretmanager.SecretManagerServiceClient()

    # Build the resource name of the secret version.
    name = client.secret_version_path(project_id, secret_id, version_id)

    # Access the secret version.
    response = client.access_secret_version(name)

    # Print the secret payload.
    #
    # WARNING: Do not print the secret in a production environment - this
    # snippet is showing how to access the secret material.
    payload = response.payload.data.decode('UTF-8')
    # logging.info('Plaintext: {}'.format(payload))
    logging.info('Secret accessed for  :' + secret_id)
    return payload
0
votes

This what I wanted

GSA_TOKEN=$(gcloud auth print-access-token --impersonate-service-account mygsa)
docker run --env GOOGLE_APPLICATION_CREDENTIALS=$GSA_TOKEN my-image