这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@bowens-stripe
Copy link
Contributor

@bowens-stripe bowens-stripe commented Apr 23, 2025

Overview

as title, this PR adds support for basic CRUD of HumioGroups in HumioOperator to manage user groups in LogScale, as well as the functionalities to assign and unassign (existing) roles to / from these groups that are associated with (existing) views.

I am using this PR which added HumioView heavily as a reference, as well as existing code for HumioRepository

Test

make test passes locally. Please feel free to advice on additional testing strategies as needed!

@bowens-stripe bowens-stripe requested a review from a team as a code owner April 23, 2025 20:16
@bowens-stripe bowens-stripe force-pushed the bowens-add-humio-group branch from d8f6242 to c9f0a01 Compare April 23, 2025 20:42
@bowens-stripe bowens-stripe force-pushed the bowens-add-humio-group branch from 4571097 to 95e0b91 Compare April 23, 2025 20:46
Copy link
Contributor

@wxu-stripe wxu-stripe left a comment

Choose a reason for hiding this comment

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

Some comments, nothing is hard blocking

}
}

mutation CreateGroup(
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe keep the name consistent as AddGroup?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Create* is consistent with the function naming for other resources though, so we either match with the graphQL API name or follow the same convention as repos and views for example. I think Create* is cleaner overall and makes the golang code easier to find at least


const (
// HumioGroupStateUnknown is the Unknown state of the group
HumioGroupStateUnknown = "Unknown"
Copy link
Contributor

Choose a reason for hiding this comment

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

Any idea how we get this state?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

line 116 in the controller code sets this state, looks like its from generic API errors

externalClusterName:
description: |-
ExternalClusterName refers to an object of type HumioExternalCluster where the Humio resources should be created.
This conflicts with ManagedClusterName.
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we want validation to make sure they're not both provided?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

mutation DeleteGroup(
$GroupId: String!
) {
removeGroup(
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar here, tho maybe not as bad, since your go function has the same naming.

defer func(ctx context.Context, hg *humiov1alpha1.HumioGroup) {
_, err := r.HumioClient.GetGroup(ctx, humioHttpClient, req, hg)
if errors.As(err, &humioapi.EntityNotFound{}) {
_ = r.setState(ctx, humiov1alpha1.HumioGroupStateNotFound, hg)
Copy link
Contributor

Choose a reason for hiding this comment

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

We're ignoring the errors here? Maybe at least log it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I believe the "finalizer" acts on this error state "eventually". for this part I am mostly copying the existing logic from other controllers, would love if someone from CrowdStrike can confirm this is correct though

@SaaldjorMike
Copy link
Contributor

@bowens-stripe Thank you for this contribution. Much appreciated.

I do have a few changes I'd like to see before this is ready to get merged in. Would you mind if I take your branch and make some adjustments to it?

Can you tell me if you strictly need support for assigning existing roles to the group (as in, roles that are not managed by the operator), or if it would be OK to only allow role assignments to roles that the operator manages?

For context, LogScale supports 3 different "types/classes" of permissions, and the current state of this PR only deals with 1 of the 3 types, namely "view permissions". We intend to add support for all of these 3 types of role permissions and mechanisms for assigning them to groups. If you're able to answer my two questions above, then I'd like to pick this up and continue the work based on your contribution.

@bowens-stripe
Copy link
Contributor Author

@SaaldjorMike I just added you as a collaborator on my fork, feel free to add anything to the branch!

Can you tell me if you strictly need support for assigning existing roles to the group (as in, roles that are not managed by the operator), or if it would be OK to only allow role assignments to roles that the operator manages?

I dont really "need" that, but I was just planning to use the Admin/Member/Reader role created automatically for us with these groups. If that's not the recommended way I can also make fresh roles to go along with the groups. (which needs a separate PR to create roles in humio-operator probably)

@bowens-stripe
Copy link
Contributor Author

@SaaldjorMike
separately, do you think this PR with only "view permissions" as-is is merge-able? Or you would rather get all 3 covered and merged them together? (and if the latter, do you have a rough time estimate for that?)

asking because it affects planning on our side to decide what to pick up next

@SaaldjorMike
Copy link
Contributor

SaaldjorMike commented May 14, 2025

@SaaldjorMike I just added you as a collaborator on my fork, feel free to add anything to the branch!

Can you tell me if you strictly need support for assigning existing roles to the group (as in, roles that are not managed by the operator), or if it would be OK to only allow role assignments to roles that the operator manages?

I dont really "need" that, but I was just planning to use the Admin/Member/Reader role created automatically for us with these groups. If that's not the recommended way I can also make fresh roles to go along with the groups. (which needs a separate PR to create roles in humio-operator probably)

Awesome. I'll probably end up just pushing a branch directly to the upstream repo based on your branch, and continue working on it there. This way all the github actions workflows that runs test and so on will work to validate the work.

@SaaldjorMike separately, do you think this PR with only "view permissions" as-is is merge-able? Or you would rather get all 3 covered and merged them together? (and if the latter, do you have a rough time estimate for that?)

asking because it affects planning on our side to decide what to pick up next

I do not see this is mergeable just yet, but I should be able to pick this one up alongside support for all the types of roles (which I'm already working on), including ways of assigning the roles to groups. The primary reason is that I'd like to move the group assignment part into the new CRD's for the roles for each of the 3 types of permissions. The primary reasoning is to keep the "who can assign this system permission role" as part of the CRUD of the "system permission role" itself, rather than on the "generic" group. I believe this creates a slightly better situation for the user that'll be setting up k8s RBAC rules for who can manage which types of roles and which groups they are assigned to.

My overall plan is like this:

  1. Merge support for CRUD of the 3 types of roles. I already have Introduce HumioSystemPermissionRole CRD #974 and Introduce HumioOrganizationPermissionRole CRD #975 that'll soon be ready. I just need the last one, which is the one for "view permissions", which is what you're asking for as part of this PR.
  2. Once the 3 new CRD's have been introduced, I'll be continuing the work started here. And I intend to push the comments to the upstream repo, then first remove the "assignments" part of HumioGroup. Get that updated variant of this code for HumioGroup merged in. Perhaps there's a few more changes, I'll figure that out.
  3. At this stage there'll be 4 new CRD's. 1 CRD for HumioGroup. 3 CRD's for roles, one per type of permission. I'll then be updating the 3 CRD's for roles to include which groups the roles are assigned to. So I intend to move the "which groups is this role assigned to" onto the role itself, rather than part of the HumioGroup CRD.

To answer your question on an estimate for when: I intend to get all the 4 new CRD's wrapped up this month.

@SaaldjorMike
Copy link
Contributor

I've opened #976 which uses the upstream branch that is based on your work. I'll circle back to working on the HumioViewPermissionRole CRD shortly, and after that I'll be doing the updates outlined above in the branch for #976

@bowens-stripe
Copy link
Contributor Author

@SaaldjorMike sounds good, thank you! I just subscribed myself to #976 , please keep us posted :)

@SaaldjorMike
Copy link
Contributor

@bowens-stripe Quick update. I've now merged the CRD's for roles and groups today. This means I now have all the building blocks I need to extend the role CRD's with mechanisms for assigning the roles to groups.

@bowens-stripe
Copy link
Contributor Author

@SaaldjorMike thank you for the update! are there plans to cut a release with the new CRDs now or that's coming after the role assignments piece?

@SaaldjorMike
Copy link
Contributor

@SaaldjorMike thank you for the update! are there plans to cut a release with the new CRDs now or that's coming after the role assignments piece?

Currently I do not intend to push out a release until the role assignment work is done, as I didn't feel like it was of as much use without the role assignment mechanisms. I expect I'll be able to get the role assignment work done within days rather than weeks so I thought I might as well just wait until that lands before cutting a new release.

We can adjust the plans if needed, so if you think it is useful for us to prioritize cutting the new release before the role assignment work is done, let me know and I'll see what I can do.

@bowens-stripe
Copy link
Contributor Author

I expect I'll be able to get the role assignment work done within days rather than weeks so I thought I might as well just wait until that lands before cutting a new release.

that's awesome to know! waiting until after that sounds good to me, thank you! @SaaldjorMike

@SaaldjorMike
Copy link
Contributor

@bowens-stripe Quick update. I just opened up #984 to add some functionality for assigning roles to groups. It may still need a bit more work, but I've shared this around internally for some review/feedback.

@SaaldjorMike
Copy link
Contributor

@bowens-stripe I'm going to close this PR now. The addition of the new CRD's have already been merged, and as soon as #984 gets merged, I'll see what I can do about getting a new release out with these features.

Thank you again for your contributions here. Much appreciated.

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

Successfully merging this pull request may close these issues.

3 participants