Answers: <p>Yes, your approach sounds okay to me. I am not sure how you &quot;ship&quot; machines but it is a good idea to use a service account per machine as you can <a href="https://cloud.google.com/iam/docs/creating-managing-service-account-keys#deleting_service_account_keys" rel="nofollow noreferrer">delete</a> the service account key if the machine ever becomes compromised.</p>
  <p>You can, and should, fully automate the process of generating the credentials key files using the Google APIs or gcloud cli.</p>
  <p>It is best practice to periodically rotate (re-issue) credentials key files. This is in case they are accidentally leaked in a way that you do not notice. If you always revoke the key and issue a new one every month then it limits the total damage somewhat.</p>
  <p>If you do rotate keys then you have a key distribution problem. How do you securely distribute the new credentials key files onto machines you shipped in the past? You can use GnuPG to <a href="https://www.gnupg.org/gph/en/manual/c14.html#AEN25" rel="nofollow noreferrer">create</a> a public-private key pair on every host. Each month you can run a script that generates a new credentials key file per machine, encrypt it with the machine's public GPG key, then <a href="https://cloud.google.com/iam/docs/creating-managing-service-account-keys#deleting_service_account_keys" rel="nofollow noreferrer">delete</a> the old service account keys.</p>
  <p>The script that pushes images to a bucket must then periodically &quot;phone home&quot; to collect a fresh GPG encrypted credentials key file. It can then <a href="https://devhints.io/gnupg#decrypting" rel="nofollow noreferrer">decrypt</a> it with its own private key. One way to do this is to put the encrypted keys into a different bucket. Create a single service account that can only read that bucket. Create a single credentials key file for that service account that you install onto every machine. That key can then only be used to only collect encrypted keys that can only be decrypted on the correct host.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-12-26T23:15:58.637Z
Answers: 2020-12-29T07:04:37.307Z
Answers: 2020-12-29T07:04:37.307Z
Answers: simbo1905
Body: <p>We're making some machines in which there's a part which uploads the images captured by the camera to Google Cloud Storage. For this purpose what I've done is</p>
  <ol>
  <li>Create a service account for each machine.</li>
  <li>Create a custom role with permissions:</li>
  </ol>
  <blockquote>
  <pre><code>storage.objects.create
  storage.buckets.get
  storage.objects.get
  </code></pre>
  </blockquote>
  <ol start="3">
  <li>Apply this role to that service account.</li>
  <li>Download the JSON credentials key file and use this file with python script (in which I specify bucket name) to upload image to GCP Storage.</li>
  </ol>
  <p>Is this way of doing things efficient and secure given that we only ship 2-3 machines each month?</p>
  <p>Also I will have to ship JSON file with each machine, if the above method is valid, is this fine or there's any method to hide this key file?</p>
  
Tags: <google-cloud-platform><google-cloud-storage>
Title: Secure way of uploading data to Google Cloud Storage
UserDisplayName: Ayush Saini
ThreadText: # Secure way of uploading data to Google Cloud Storage
  
  (Asked by: username_0 on 2020-12-21)
  
  We're making some machines in which there's a part which uploads the images captured by the camera to Google Cloud Storage. For this purpose what I've done is
  
  1. Create a service account for each machine.
  2. Create a custom role with permissions:
  
  > ```
  > storage.objects.create
  > storage.buckets.get
  > storage.objects.get
  >
  > ```
  
  3. Apply this role to that service account.
  4. Download the JSON credentials key file and use this file with python script (in which I specify bucket name) to upload image to GCP Storage.
  
  Is this way of doing things efficient and secure given that we only ship 2-3 machines each month?
  
  Also I will have to ship JSON file with each machine, if the above method is valid, is this fine or there's any method to hide this key file?
  
  **Tags:** google-cloud-platform, google-cloud-storage
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-12-26. Score: 1
  
  Yes, your approach sounds okay to me. I am not sure how you "ship" machines but it is a good idea to use a service account per machine as you can [delete](https://cloud.google.com/iam/docs/creating-managing-service-account-keys#deleting_service_account_keys) the service account key if the machine ever becomes compromised.
  
  You can, and should, fully automate the process of generating the credentials key files using the Google APIs or gcloud cli.
  
  It is best practice to periodically rotate (re-issue) credentials key files. This is in case they are accidentally leaked in a way that you do not notice. If you always revoke the key and issue a new one every month then it limits the total damage somewhat.
  
  If you do rotate keys then you have a key distribution problem. How do you securely distribute the new credentials key files onto machines you shipped in the past? You can use GnuPG to [create](https://www.gnupg.org/gph/en/manual/c14.html#AEN25) a public-private key pair on every host. Each month you can run a script that generates a new credentials key file per machine, encrypt it with the machine's public GPG key, then [delete](https://cloud.google.com/iam/docs/creating-managing-service-account-keys#deleting_service_account_keys) the old service account keys.
  
  The script that pushes images to a bucket must then periodically "phone home" to collect a fresh GPG encrypted credentials key file. It can then [decrypt](https://devhints.io/gnupg#decrypting) it with its own private key. One way to do this is to put the encrypted keys into a different bucket. Create a single service account that can only read that bucket. Create a single credentials key file for that service account that you install onto every machine. That key can then only be used to only collect encrypted keys that can only be decrypted on the correct host.
  
  
  ---
  
  