-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
feat: Fleet app operator permissions #1986
base: master
Are you sure you want to change the base?
feat: Fleet app operator permissions #1986
Conversation
- added type string to the role variable - changed role maps from variables to locals
…because only one of them is required
…ator_name, is_user_app_operator> With this change, the admin explicitly specifies whether the app operator is a user or group. This can help to not take dependency to the value of the app operator name (i.e., previously whether user != '' or a group != '').
- removed the app operator email input and use a service account created in the module instead - removed the app operator role input and simply use the VIEW role
…ng the app_operator_team input
/gcbrun |
…le module This was changed by my local run of make docker_test_lint.
/gcbrun |
From the CI:
|
When possible, it's suggest to avoid variables in examples (as you will need to provide a value from the integration test). For example, a end to end example could first create a born in fleet cluster, and then pass the fleet project from that. |
* limitations under the License. | ||
*/ | ||
|
||
variable "project_id" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the heavy use of project_id
, I suggest clarifying:
variable "project_id" { | |
variable "fleet_project_id" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
type = string | ||
} | ||
|
||
variable "is_user_app_operator" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than introducing an additional variable, I'd suggest we try to simplify the user experience. Looks like we required user:person@google.com
or group:people@google.com
for app_operator_name
, this variable is_user_app_operator
could be eliminated?
Could even add app_operator_name
variable validation to ensure the string starts with a valid prefix: "user:", "group:", "principal:", "principalSet:"
. Then use a regex or similar to determine local.is_user_app_operator
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm now using the users
and groups
variables, by which the lists of user and group app operators can be provided to have the specified role.
One thing about the format is that a user/group is in fact an RBAC subject. The corresponding IAM principal is created accordingly, e.g., for user person@google.com
, the IAM principal would be user:person@google.com
. I defined these variables in RBAC style (rather than IAM style) to be consistent with how the same thing is done with gcloud. So as for validation, we don't have a set of acceptable prefixes with this approach.
description = "The principal role for the Fleet Scope (`VIEW`/`EDIT`/`ADMIN`)." | ||
type = string | ||
validation { | ||
condition = var.role == "VIEW" || var.role == "EDIT" || var.role == "ADMIN" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: probably could use contains(list, value)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
value = var.project_id | ||
} | ||
|
||
output "wait" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice! :)
…ions and example modules
I defined a new project for fleet testing purposes (though for now, I'm not creating a cluster in the example module). I added the test fixture to provide the project ID. |
/gcbrun |
…st fixtures This should hopefully make the app operator email available at apply time of the example module.
/gcbrun |
…rmissions I'm now building the service account email string explicitly and instead declaring depencency to the service account resource, so that for_each works without the need for applying the service account resource in advance.
/gcbrun |
…d iam service account
/gcbrun |
This seems to be the correct way to grant the necessary permissions.
/gcbrun |
1 similar comment
/gcbrun |
|
…issions The condition is a bit long, and it's possibly included in two lines in the project IAM policy. I'm trying to see if checking subconditions separately works.
/gcbrun |
…ions to just looking for log buckets in the project IAM policy
This PR introduces a Terraform module that bundles different permissions (IAM and RBAC Role Bindings) required for Fleet team management.