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
Using Skaffold with CloudRun should allow users to specify whether their provisioned service is reachable from the internet. Technically, this means that users should be able to specify IAM policy bindings for the provisioned service. This is consistent with the experience of the gcloud cli tool. It has an --allow unauthenticated option to automatically expose provisioned services to the internet.
I see two ways of implementing this behaviour:
1. Native IAM integration into Skaffold
Skaffold could add a configuration field to allow users to specify whether the deployed services should be accessible from the internet. While this would be analogous to gcloud, it is also quite restrictive and would require deep integration into Skaffold. Users might want to grant invocation permissions to groups other than allUsers, which wouldn't be compatible with this approach. On the other hand, this approach is very easy to use as a developer and greatly improves the development of applications with Skaffold.
2. Add a Post Service Deploy-Hook and a new environment variable
Adding a post-deploy hook that runs after each deployed service and exposes the service name as an environment variable would greatly enhance the developer's capabilities. Imagine if the service name (e.g. projects/{project}/locations/{location}/services/{serviceId}') could be exposed as $SKAFFOLD_CLOUDRUN_SERVICE_NAME' in hooks.
This example illustrates the idea. However, the defined hook is not run for each deployed service, but only after they have all been deployed. This behaviour isn't compatible with the proposed approach. However, there could be a custom hook type for the cloud-run service, just like host & container hooks for all other deployment methods. This would make the approach very flexible.
I am well aware that the hook type cloudrunServiceCreated is not optimally named but I think it isn't especially relevant to get the idea across. This would also break the current configuration format, which doesn't allow the hook type to be specified for CloudRun at all.
Actual behavior
When deploying CloudRun services using Skaffold, users won't be able to specify IAM policy bindings. By default, all deployed services require Cloud IAM to be accessed. This also applies when using --port-forward. This means that services deployed using Skaffold can't be accessed from the web without manual configuration.
If you use Skaffold during development (using skaffold dev), the service will be deleted on exit and re-created on invocation. This is, for lack of a better term, very annoying as you have to either run the command mentioned below or click through the Google Cloud web interface to give yourself access.
The following command can be used to allow the internet (allUsers) to access the service:
gcloud run services add-iam-policy-binding
--region=[region]
--member=allUsers
--role=roles/run.invoker
{service_name}
I'd like to stress that allUsers does not necessarily mean that the Internet can access the service. Most likely the service will be inside a VPC which will restrict incoming traffic.
Closing Remark
By implementing this feature, Skaffold will offer a more seamless development experience for CloudRun users, reducing friction in managing IAM policies and enhancing the overall developer workflow. Improving Skaffold with CloudRun by allowing users to configure service access will significantly streamline development workflows, reducing manual IAM setup.
Personally, I am not sure which approach is more in line with Skaffold's vision. I like the second more because it allows more user control. However, it also requires Skaffold to introduce a hook type just for CloudRun, which might not be desirable. Maybe there is a simpler way that I have not considered yet? I would really like to hear other people's opinions on this though.
I would also like to acknowledge that there is an inherent risk in automatically deploying your code and making it accessible from the internet using skaffold dev, if such an option were to be implemented. However, this only applies if the service's ingress control allows access from outside the VPC, or if the VPC itself is misconfigured, which I believe is not Skaffold's responsibility. I think it is reasonable to expect users to understand that there may be risks in allowing unauthenticated access to their service.
The text was updated successfully, but these errors were encountered:
Expected behavior
Using Skaffold with CloudRun should allow users to specify whether their provisioned service is reachable from the internet. Technically, this means that users should be able to specify IAM policy bindings for the provisioned service. This is consistent with the experience of the
gcloud
cli tool. It has an--allow unauthenticated
option to automatically expose provisioned services to the internet.I see two ways of implementing this behaviour:
1. Native IAM integration into Skaffold
Skaffold could add a configuration field to allow users to specify whether the deployed services should be accessible from the internet. While this would be analogous to
gcloud
, it is also quite restrictive and would require deep integration into Skaffold. Users might want to grant invocation permissions to groups other thanallUsers
, which wouldn't be compatible with this approach. On the other hand, this approach is very easy to use as a developer and greatly improves the development of applications with Skaffold.2. Add a Post Service Deploy-Hook and a new environment variable
Adding a post-deploy hook that runs after each deployed service and exposes the service name as an environment variable would greatly enhance the developer's capabilities. Imagine if the service name (e.g.
projects/{project}/locations/{location}/services/{serviceId}') could be exposed as
$SKAFFOLD_CLOUDRUN_SERVICE_NAME' in hooks.This example illustrates the idea. However, the defined hook is not run for each deployed service, but only after they have all been deployed. This behaviour isn't compatible with the proposed approach. However, there could be a custom hook type for the cloud-run service, just like host & container hooks for all other deployment methods. This would make the approach very flexible.
Actual behavior
When deploying CloudRun services using Skaffold, users won't be able to specify IAM policy bindings. By default, all deployed services require Cloud IAM to be accessed. This also applies when using
--port-forward
. This means that services deployed using Skaffold can't be accessed from the web without manual configuration.If you use Skaffold during development (using
skaffold dev
), the service will be deleted on exit and re-created on invocation. This is, for lack of a better term, very annoying as you have to either run the command mentioned below or click through the Google Cloud web interface to give yourself access.The following command can be used to allow the internet (
allUsers
) to access the service:Closing Remark
By implementing this feature, Skaffold will offer a more seamless development experience for CloudRun users, reducing friction in managing IAM policies and enhancing the overall developer workflow. Improving Skaffold with CloudRun by allowing users to configure service access will significantly streamline development workflows, reducing manual IAM setup.
Personally, I am not sure which approach is more in line with Skaffold's vision. I like the second more because it allows more user control. However, it also requires Skaffold to introduce a hook type just for CloudRun, which might not be desirable. Maybe there is a simpler way that I have not considered yet? I would really like to hear other people's opinions on this though.
I would also like to acknowledge that there is an inherent risk in automatically deploying your code and making it accessible from the internet using
skaffold dev
, if such an option were to be implemented. However, this only applies if the service's ingress control allows access from outside the VPC, or if the VPC itself is misconfigured, which I believe is not Skaffold's responsibility. I think it is reasonable to expect users to understand that there may be risks in allowing unauthenticated access to their service.The text was updated successfully, but these errors were encountered: