You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The guide for integrating Google Cloud service account credentials has the following issues:
The command to generate the base64 encoded value doesn't generate the correct format due to the service account credentials containing whitespaces and new lines within the JSON file. So the output of the base64 value by default applies line wrapping by default which in turn causes issues when trying to use that value inside of a .env file with Docker etc.
Also there is a security concern with one of the approaches suggested in the docs which is to put the base64 encoded value of the service account credentials directly within the Kestra configuration. This poses a huge security issue as the Kestra config will usually be committed to a GitHub repo. This means that anyone who has "read" access to the repo can simply take the base64 encoded value and decode it to get the service account credentials and carry out nefarious actions with it.
The value above has line wrapping which adds new lines to the base64 value. So that means that the whole value will not be passed into the .env file correctly. You can see this problem when inspecting the environment variables on a standalone linux environment or within a docker container e.g. using Docker Desktop.
However, this can be remedied by using the following command instead: cat service-account.json | base64 -w 0
This command will remove any line wrapping which will give you the correct base64 encoded string format. You can be rest assured that this doesn't have any implications as decoding it will give you back the original JSON payload for your service account credential.
So based on this observation, I suggest updating the docs to include the following modifications to the guide:
Remove the guide regarding storing the credentials directly in the Kestra config due to security concerns.
Update the bash command to use the command shown above in the solution and prefer the .env approach.
The text was updated successfully, but these errors were encountered:
Description
The guide for integrating Google Cloud service account credentials has the following issues:
The command to generate the base64 encoded value doesn't generate the correct format due to the service account credentials containing whitespaces and new lines within the JSON file. So the output of the base64 value by default applies line wrapping by default which in turn causes issues when trying to use that value inside of a
.env
file with Docker etc.Also there is a security concern with one of the approaches suggested in the docs which is to put the base64 encoded value of the service account credentials directly within the Kestra configuration. This poses a huge security issue as the Kestra config will usually be committed to a GitHub repo. This means that anyone who has "read" access to the repo can simply take the base64 encoded value and decode it to get the service account credentials and carry out nefarious actions with it.
An example has been provided below:
service-account.json
(this is a fake credential):Following the current docs suggests using the following command to generate the base64 value:
cat service-account.json | base64
The value above has line wrapping which adds new lines to the base64 value. So that means that the whole value will not be passed into the
.env
file correctly. You can see this problem when inspecting the environment variables on a standalone linux environment or within a docker container e.g. using Docker Desktop.However, this can be remedied by using the following command instead:
cat service-account.json | base64 -w 0
This command will remove any line wrapping which will give you the correct base64 encoded string format. You can be rest assured that this doesn't have any implications as decoding it will give you back the original JSON payload for your service account credential.
So based on this observation, I suggest updating the docs to include the following modifications to the guide:
.env
approach.The text was updated successfully, but these errors were encountered: