<p>I've build the following script:</p>

<pre><code>import boto
import sys
import gcs_oauth2_boto_plugin

def check_size_lzo(ds):

# URI scheme for Cloud Storage.

    CLIENT_ID = 'myclientid'
    CLIENT_SECRET = 'mysecret'

    GOOGLE_STORAGE = 'gs'

    dir_file= 'date_id={ds}/apollo_export_{ds}.lzo'.format(ds=ds)



    gcs_oauth2_boto_plugin.SetFallbackClientIdAndSecret(CLIENT_ID, CLIENT_SECRET)
    uri = boto.storage_uri('my_bucket/data/apollo/prod/'+ dir_file, GOOGLE_STORAGE)
    key = uri.get_key()



    if key.size &lt; 45379959:
        raise ValueError('umg lzo file is too small, investigate')
    else:
        print('umg lzo file is %sMB' % round((key.size/1e6),2))



if __name__ == "__main__":

     check_size_lzo(sys.argv[1])
</code></pre>

<p>It works fine locally but when I try and run on kubernetes cluster I get the following error:</p>

<pre><code>boto.exception.GSResponseError: GSResponseError: 403 Access denied to 'gs://my_bucket/data/apollo/prod/date_id=20180628/apollo_export_20180628.lzo'
</code></pre>

<p>I have updated the .boto file on my cluster and added my oauth client id and secret but still having the same issue. </p>

<p>Would really appreciate help resolving this issue.</p>

<p>Many thanks!</p>

<p>If it works in one environment and fails in another, I assume that you're getting your auth from a .boto file (or possibly from the OAUTH2_CLIENT_ID environment variable), but your kubernetes instance is lacking such a file. That you got a 403 instead of a 401 says that your remote server is correctly authenticating as somebody, but that somebody is not authorized to access the object, so presumably you're making the call as a different user.</p>

<p>Unless you've changed something, I'm guessing that you're getting <a href="https://cloud.google.com/docs/authentication/production#obtaining_credentials_on_compute_engine_kubernetes_engine_app_engine_flexible_environment_and_cloud_functions" rel="nofollow noreferrer">the default Kubernetes Engine auth</a>, with means <a href="https://cloud.google.com/compute/docs/access/service-accounts#compute_engine_default_service_account" rel="nofollow noreferrer">a service account associated with your project</a>. That service account probably hasn't been granted read permission for your object, which is why you're getting a 403. Grant it read/write permission for your GCS resources, and that should solve the problem.</p>

<p>Also note that by default the default credentials aren't scoped to include GCS, so <a href="https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#changeserviceaccountandscopes" rel="nofollow noreferrer">you'll need to add that as well</a> and then restart the instance.</p>
