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

gcp: support projects with no default permissions #3656

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

3u13r
Copy link
Member

@3u13r 3u13r commented Feb 20, 2025

Context

When creating VMs we used to rely on the following points:

  1. The default project service account is automatically attached to every VM in the project, which doesn't override it
  2. The default service account used to have many permissions due having the Editor role attached by default (see: https://cloud.google.com/iam/docs/service-account-types#default)
  3. Though, the scopes added to the VM filtered how this service account could be used

Since GCP now doesn't give the project service account Editor by default, we need to create our own service account with minimal permissions. Note that the filtering over scopes is deprecated, one should simply attach a service account with minimal permissions and maximum scope.

Not only the Bootstrapper on the VM but also the constellation-operator and join-service automatically used the project service account per default, since we didn't explicitly set the service account already create for (and used by) other cluster components.
Since we want the VMs permissions to be as narrow as possible, we need to pass the in-cluster service account to also the constellation-operator and join-service.

Proposed change(s)

  • Create a second very narrow, read-only service account and attach it to VMs
  • Don't filter via scope anymore
  • Attach the in-cluster service account to the constellation-operator and join-service

Checklist

How to test:

  • Create/upgrade your gcp iam credentials
  • Successfully start a cluster, neither the bootstrapper, operator or the joinservice should error

@3u13r 3u13r added the feature This introduces new functionality label Feb 20, 2025
@3u13r 3u13r added this to the v2.21.0 milestone Feb 20, 2025
Copy link

netlify bot commented Feb 20, 2025

Deploy Preview for constellation-docs canceled.

Name Link
🔨 Latest commit ce22bed
🔍 Latest deploy log https://app.netlify.com/sites/constellation-docs/deploys/67cee5c9cf4c420008533221

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the sake of not further complicating the iam create command, should we make it default to use the serviceAccountID for the serviceAccountVMID if the latter is not present? (i.e. the current behavior)

Copy link
Member Author

@3u13r 3u13r Feb 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, was also not sure about that. I think we can go with not having a flag at all and just appending "-vm" to the other one. Though of course something like "my-in-cluster-service-account-vm" is also weird. In a ideal goal scenario, we'd just have a given prefix as for the cluster creation and we can just derive everything from there.

Though, I'm interested about hearing opinions about what to implement in this PR. If we get one more vote for falling back to the other flag, then I'll go with that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just making it a prefix is a great idea. Would also resemble what we currently have on AWS.

Copy link
Member Author

@3u13r 3u13r Feb 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess then I add a prefix flag to the command. While this is counter-intuitive behavior: should we make it have precedence over the serviceAccountID if both are set, so we can set both in the CI and deprecate the old one slowly?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Id not have both but remove serviceAccountID directly. (we can have breaking changes)

Having both would indeed be counter-intuitive. Or what was your point for that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should have such breaking changes. One example is the upgrade CI e2e test. If you specify too many flags during iam create it just fails, therefore, I think we need to have a migration plan (In my opinion not only for the e2e test but also for users).

@3u13r 3u13r added the breaking change Change breaks existing API or configuration. label Feb 20, 2025
@3u13r 3u13r force-pushed the euler/feat/gcp/vm-serviceaccount branch 2 times, most recently from b1b1b65 to 29cab93 Compare March 10, 2025 10:08
@3u13r 3u13r added the iam upgrade Indicate that a cluster upgrade requires `iam upgrade apply` label Mar 10, 2025
@3u13r 3u13r force-pushed the euler/feat/gcp/vm-serviceaccount branch from 29cab93 to e152be0 Compare March 10, 2025 10:59
@3u13r 3u13r force-pushed the euler/feat/gcp/vm-serviceaccount branch from e152be0 to 8c8587b Compare March 10, 2025 12:49
@3u13r 3u13r force-pushed the euler/feat/gcp/vm-serviceaccount branch from 8c8587b to ce22bed Compare March 10, 2025 13:14
@3u13r 3u13r marked this pull request as ready for review March 10, 2025 13:21
Copy link
Contributor

Coverage report

Package Old New Trend
cli/internal/cloudcmd 63.90% 63.70% ↘️
cli/internal/cmd 57.90% 57.90% ↔️
cli/internal/terraform 69.60% 69.80% ↗️
internal/config 77.10% 77.20% ↗️

Copy link
Member

@daniel-weisse daniel-weisse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the new service account attached to the VMs have sufficient permissions for the GCP CSI driver?

Comment on lines +25 to +26
case cloudprovider.GCP:
return true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a TODO to remove this after the next release (just in case)

Comment on lines +35 to +36
cmd.Flags().String("serviceAccountID", "", "[Deprecated use \"--prefix\"]ID for the service account that will be created (required)\n"+
"Must be 6 to 30 lowercase letters, digits, or hyphens. This flag is mutually exclusive with --prefix.")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
cmd.Flags().String("serviceAccountID", "", "[Deprecated use \"--prefix\"]ID for the service account that will be created (required)\n"+
"Must be 6 to 30 lowercase letters, digits, or hyphens. This flag is mutually exclusive with --prefix.")
cmd.Flags().String("serviceAccountID", "", "ID for the service account that will be created\n"+
"Must be 6 to 30 lowercase letters, digits, or hyphens. This flag is mutually exclusive with --prefix.")
must(cmd.Flags().MarkDeprecated("serviceAccountID", "use \"--prefix\" instead"]

Use MarkDeprecated instead of manually adding a deprecation note.
This will cause the flag to not show up when running the command with --help and will print Flag --serviceAccountID has been deprecated, use "--prefix" instead when using it.

},
}
}

func (c *gcpIAMCreator) printConfirmValues(cmd *cobra.Command) {
cmd.Printf("Project ID:\t\t%s\n", c.flags.projectID)
cmd.Printf("Name Prefix:\t\t%s\n", c.flags.namePrefix)
cmd.Printf("Service Account ID:\t%s\n", c.flags.serviceAccountID)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
cmd.Printf("Service Account ID:\t%s\n", c.flags.serviceAccountID)
if c.flags.serviceAccountID != "" {
cmd.Printf("Service Account ID:\t%s\n", c.flags.serviceAccountID)
}

Should now only be printed when the --prefix flag wasn't set
Similarly, we might want to omit the output for name prefix if only --serviceAccountID was set

@@ -102,7 +102,7 @@ If you encounter any problem with the following steps, make sure to use the [lat
<TabItem value="gcp" label="GCP">

```bash
constellation iam create gcp --projectID=yourproject-12345 --zone=europe-west2-a --serviceAccountID=constell-test --update-config
constellation iam create gcp --projectID=yourproject-12345 --zone=europe-west2-a --serviceAccountVMID=constell-test-vm --serviceAccountID=constell-test --update-config
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
constellation iam create gcp --projectID=yourproject-12345 --zone=europe-west2-a --serviceAccountVMID=constell-test-vm --serviceAccountID=constell-test --update-config
constellation iam create gcp --projectID=yourproject-12345 --zone=europe-west2-a --prefix=constell-test --update-config

Copy link
Contributor

@elchead elchead left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

owned files lgtm

zone = local.zone
region = local.region
source = "https://github.com/edgelesssys/constellation/releases/download/$VERSION/terraform-module.zip//terraform-module/iam/gcp"
sproject_id = local.project_id
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
sproject_id = local.project_id
project_id = local.project_id

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Change breaks existing API or configuration. feature This introduces new functionality iam upgrade Indicate that a cluster upgrade requires `iam upgrade apply`
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants