Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Support for Configurable CloudRun IAM Policy Bindings in Skaffold #9530

Open
paulvonallwoerden opened this issue Sep 25, 2024 · 0 comments

Comments

@paulvonallwoerden
Copy link

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 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.

deploy:
  cloudrun:
    projectid: {my_project}
    region: {my_region}
    allowUnauthenticatedInvocation: true

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.

deploy:
  cloudrun:
    projectid: {my_project}
    region: {my_region}
  hooks:
    after:
      - cloudrunServiceCreated:
          command: |
              gcloud run services add-iam-policy-binding
                --region={my_region}
                --member=allUsers
                --role=roles/run.invoker
                "$SKAFFOLD_CLOUDRUN_SERVICE_NAME"

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant