Authorize Access to Object Storage on Google Cloud

This guide will walk you through configuring Rok to have access to object storage resources on Google Cloud.

What You’ll Need

Procedure

  1. Go to your GitOps repository, inside your rok-tools management environment:

    root@rok-tools:~# cd ~/ops/deployments

  2. Edit rok/rok-cluster/overlays/deploy/kustomization.yaml to set the parent of the deploy kustomization overlay to gke:

    bases: - ../gke # <-- Edit this line to point to the gke overlay

  3. Retrieve your bucket prefix. Copy the output to your clipboard, as you are going to use this value in the next step:

    root@rok-tools:~/ops/deployments# echo ${BUCKET_PREFIX?} rok-myproject-us-east1-b-arrikto-cluster

  4. Edit rok/rok-cluster/overlays/deploy/patches/configvars.yaml to set daemons.s3d.bucket_prefix to your bucket prefix.

    spec: configVars: daemons.s3d.bucket_prefix: <BUCKET_PREFIX> # <-- Update this line with your bucket prefix

  5. Retrieve the ID of your Google project. Copy the output to your clipboard, as you are going to use this value in the next step:

    root@rok-tools:~/ops/deployments# echo ${PROJECT_ID?} myproject

  6. Edit rok/rok-cluster/overlays/deploy/patches/configvars.yaml to set daemons.s3d.gcp.project_id to the ID of your Google project.

    spec: configVars: daemons.s3d.gcp.project_id: <PROJECT_ID> # <-- Update this line with your GCP project ID

  7. Edit rok/rok-cluster/overlays/deploy/patches/storage.yaml to set the spec.s3.endpoint field to https://storage.googleapis.com.

    spec: s3: endpoint: https://storage.googleapis.com # <-- Update this line with the Google Cloud Storage endpoint.

  8. Retrieve the GCP region. Copy the output to your clipboard, as you are going to use this value in the next step:

    root@rok-tools:~/ops/deployments# echo ${REGION?} us-east1

  9. Edit rok/rok-cluster/overlays/deploy/patches/storage.yaml to set the spec.s3.region field to your GCP region.

    spec: s3: region: <REGION> # <-- Update this line with your GCP region

  10. Retrieve the email of the Google service account you created for Rok. Copy the output to your clipboard, as you are going to use this value in the next step:

    root@rok-tools:~/ops/deployments# echo ${GCP_SERVICE_ACCOUNT_EMAIL?} rok-arrikto-cluster@myproject.iam.gserviceaccount.com

  11. Edit rok/rok-cluster/overlays/deploy/patches/storage.yaml to set the spec.s3.GCPServiceAccount field to the email of the Google service account you created for Rok.

    spec: s3: GCPServiceAccount: <GCP_SERVICE_ACCOUNT_EMAIL> # <-- Update this line with your GCP service account email

  12. Track all changes in the git repository:

    root@rok-tools:~/ops/deployments# git add rok/rok-cluster

  13. Commit the changes:

    root@rok-tools:~/ops/deployments# git commit -m "Configure object storage access for Rok"

Verify

  1. Go to your GitOps repository, inside your rok-tools management environment:

    root@rok-tools:~# cd ~/ops/deployments

  2. Deploy a Pod using the service account of Rok:

    1. Create the Rok namespaces:

      root@rok-tools:~/ops/deployments# rok-deploy --apply rok/rok-namespaces/overlays/deploy

    2. Render the rok-verify-service-account-gke manifest template:

      root@rok-tools:~/ops/deployments# j2 rok/rok-test/rok-verify-service-account-gke.yaml.j2 \ > -o rok/rok-test/rok-verify-service-account-gke.yaml

      Alternatively, download the rok-verify-service-account-gke manifest template provided below and use it locally.

      rok-verify-service-account-gke.yaml.j2
      Download file
      1# This file is part of Rok.
      2#
      3# Copyright © 2021 Arrikto Inc. All Rights Reserved.
      4-10
      4
      5apiVersion: v1
      6kind: ServiceAccount
      7metadata:
      8 labels:
      9 app.kubernetes.io/part-of: rok-verify
      10 annotations:
      11 iam.gke.io/gcp-service-account: {{GCP_SERVICE_ACCOUNT_EMAIL}}
      12 name: {{ROK_CLUSTER_NAME}}
      13 namespace: {{ROK_CLUSTER_NAMESPACE}}

    3. Render the rok-verify-storage-access-gke manifest template:

      root@rok-tools:~/ops/deployments# j2 rok/rok-test/rok-verify-storage-access-gke.yaml.j2 \ > -o rok/rok-test/rok-verify-storage-access-gke.yaml

      Alternatively, download the rok-verify-storage-access-gke manifest template provided below and use it locally.

      rok-verify-storage-access-gke.yaml.j2
      Download file
      1# This file is part of Rok.
      2#
      3# Copyright © 2021 Arrikto Inc. All Rights Reserved.
      4-20
      4
      5apiVersion: v1
      6kind: Pod
      7metadata:
      8 name: rok-verify-storage-access
      9 namespace: {{ROK_CLUSTER_NAMESPACE}}
      10spec:
      11 serviceAccountName: {{ROK_CLUSTER_NAME}}
      12 containers:
      13 - name: rok-verify-storage-access
      14 image: gcr.io/arrikto/rok-tools:release-2.0-l0-release-2.0.1
      15 imagePullPolicy: IfNotPresent
      16 workingDir: /root
      17 env:
      18 - name: BUCKET_PREFIX
      19 value: "{{BUCKET_PREFIX}}"
      20 - name: GCP_SERVICE_ACCOUNT_EMAIL
      21 value: "{{GCP_SERVICE_ACCOUNT_EMAIL}}"
      22 - name: REGION
      23 value: "{{REGION}}"

      Air Gapped

      Edit the rendered manifest rok/rok-test/rok-verify-storage-access-gke.yaml to use the mirrored rok-tools image from your internal registry:

      containers: - name: rok-verify-storage-access image: gcr.io/arrikto/rok-tools:release-2.0-l0-release-2.0.1 # <-- Edit this line to point to your mirrored rok-tools image

    4. Commit the changes:

      root@rok-tools:~/ops/deployments# git commit -am "Configure Pod and SA to verify storage access"

    5. Create the rok service account:

      root@rok-tools:~/ops/deployments# kubectl create -f rok/rok-test/rok-verify-service-account-gke.yaml serviceaccount/rok created

      Troubleshooting

      The service account already exists

      If you have already deployed Rok and created its service account, then the above command will fail with the following error:

      Error from server (AlreadyExists): error when creating "rok/rok-test/rok-verify-service-account-gke.yaml": serviceaccounts "rok" already exists

      In this case, ignore this error and proceed with the verification steps below.

    6. Deploy the rendered rok-verify-storage-access-gke manifest to your GKE cluster:

      root@rok-tools:~/ops/deployments# kubectl apply -f rok/rok-test/rok-verify-storage-access-gke.yaml pod/rok-verify-storage-access created

    7. Wait for the rok-verify-storage-access Pod to come up:

      root@rok-tools:~/ops/deployments# kubectl get pods rok-verify-storage-access \ > -n ${ROK_CLUSTER_NAMESPACE?} NAME READY STATUS RESTARTS AGE rok-verify-storage-access 1/1 Running 0 20s

  3. Verify the Pod credentials:

    1. Enter the Pod:

      root@rok-tools:~/ops/deployments# kubectl exec rok-verify-storage-access \ > -itn ${ROK_CLUSTER_NAMESPACE?} \ > -- /bin/bash

    2. Ensure that the Rok Google service account is the active account, that is, the output of the following command is OK:

      root@rok-verify-storage-access:~# gcloud auth list \ > --filter="status=ACTIVE AND account=${GCP_SERVICE_ACCOUNT_EMAIL?}" \ > --format=json \ > | jq -e '.[]' >/dev/null \ > && echo OK \ > || echo FAIL OK

  4. Perform a request towards Cloud Storage:

    1. Check if the chocks-ca Rok bucket exists. If so, go to step 4c.

      root@rok-verify-storage-access:~# gsutil ls -b gs://${BUCKET_PREFIX?}-chocks-ca/ BucketNotFoundException: 404 gs://rok-myproject-us-east1-b-arrikto-cluster-chocks-ca bucket does not exist.

      Troubleshooting

      Command failed with ‘403 Forbidden’

      If the above command failed with the following Python errors:

      urllib.error.HTTPError: HTTP Error 403: Forbidden apitools.base.py.exceptions.CommunicationError: Could not reach metadata service: Forbidden

      then this means that the Kubernetes service account cannot impersonate the Google service account. This can happen if the Kubernetes service account does not have a role binding for the iam.workloadIdentityUser role on the Google service account. Make sure you have followed the Create Cloud Identity section to set up the necessary role bindings.

      Command failed with ‘403 AccessDenied’

      If the above command failed with the following error:

      AccessDeniedException: 403 rok-arrikto-cluster@myproject.iam.gserviceaccount.com does not have storage.buckets.create access to the Google Cloud project.

      then this means that the Kubernetes service account can impersonate the Google service account, but the Google service account does not have the storage.buckets.get permission on this bucket. Make sure you have followed the Create Cloud Identity section to set up the necessary role bindings.

    2. Create the Rok bucket:

      root@rok-verify-storage-access:~# gsutil mb -l ${REGION?} gs://${BUCKET_PREFIX?}-chocks-ca/ Creating gs://rok-myproject-us-east1-b-arrikto-cluster-chocks-ca/...

      Troubleshooting

      Command failed with ‘403 AccessDenied’

      If the above command failed with the following error:

      AccessDeniedException: 403 rok-arrikto-cluster@myproject.iam.gserviceaccount.com does not have storage.buckets.create access to the Google Cloud project.

      then this means that the Kubernetes service account can impersonate the Google service account, but the Google service account does not have the storage.buckets.create permission. Make sure you have followed the Create Cloud Identity section to set up the necessary role bindings.

    3. List the objects in the Rok bucket:

      root@rok-verify-storage-access:~# gsutil ls gs://${BUCKET_PREFIX?}-chocks-ca/

      Troubleshooting

      Command failed with ‘403 AccessDenied’

      If the above command failed with the following error:

      AccessDeniedException: 403 rok-arrikto-cluster@myproject.iam.gserviceaccount.com does not have storage.buckets.create access to the Google Cloud project.

      then this means that the Kubernetes service account can impersonate the Google service account, but the Google service account does not have the storage.objects.list permission on this bucket. Make sure you have followed the Create Cloud Identity section to set up the necessary role bindings.

    4. Ensure that the output of the above command is empty, or it lists some objects. This means that you have successfully impersonated the Rok Google service account and authorized a request with it.

  5. Clean up the Pod:

    1. Return to your management environment:

      root@rok-verify-storage-access:~# exit

    2. Delete the Pod:

      root@rok-tools:~/ops/deployments# kubectl delete -f rok/rok-test/rok-verify-storage-access-gke.yaml pod "rok-verify-storage-access" deleted

    3. Delete the Rok service account, if you created it in this Verify section (step 2e):

      root@rok-tools:~/ops/deployments# kubectl delete sa \ > -l "app.kubernetes.io/part-of=rok-verify" \ > -n ${ROK_CLUSTER_NAMESPACE?} serviceaccount "rok" deleted

Summary

You have successfully provided Rok with access to the object storage service of your cloud provider.

What’s Next

The next step is to grant Rok access to Arrikto’s private container registry, so that it can pull images from it.

PreviousNext