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

CLI-979 Refactor ccloud kafka acl parameter names to match those of REST #943

Merged
merged 14 commits into from
Sep 9, 2021

Conversation

MuweiHe
Copy link
Contributor

@MuweiHe MuweiHe commented Jul 27, 2021

Checklist

  1. [CRUCIAL] Is the change for CP or CCloud functionalities that are already live in prod?

    • yes: ok
  2. Did you add/update any commands that accept secrets as args/flags?

    • no: ok

What

Change ccloud kafka acl flag names to match the REST Proxy params

Changes would be: {"ServiceAccountId", "Permission", "Operation", "Resource", "Name", "Type"} --> {"Principal", "Permission", "Operation", "ResourceType", "ResourceName", "PatternType"}

Note: this is a breaking change that would ship in ccloud v2.0

References

Test&Review

@MuweiHe MuweiHe requested a review from a team as a code owner July 27, 2021 00:21
Copy link
Contributor

@DABH DABH left a comment

Choose a reason for hiding this comment

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

Some questions about some of the fields, in particular Principal vs. ServiceAccountId, but otherwise this is mostly good

internal/cmd/ksql/command_test.go Outdated Show resolved Hide resolved
@@ -345,8 +345,8 @@ func PrintACLsFromKafkaRestResponseWithMap(cmd *cobra.Command, aclGetResp kafkar
cmd.Flags().StringP(output.FlagName, output.ShortHandFlag, output.DefaultValue, output.Usage)
}

aclListFields := []string{"UserId", "ServiceAccountId", "Permission", "Operation", "Resource", "Name", "Type"}
aclListStructuredRenames := []string{"user_id", "service_account_id", "permission", "operation", "resource", "name", "type"}
aclListFields := []string{"Principal", "ServiceAccountId", "Permission", "Operation", "ResourceType", "ResourceName", "PatternType"}
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, why do we have both Principal and ServiceAccountId here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

principal is like 'User: 12345' and service account is 'sa-12345'

Copy link
Contributor

Choose a reason for hiding this comment

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

So does the REST Proxy API also have a service account ID field / service account resource ID field? Or are you saying that this is just an extra field that we show in the CLI, even though the REST Proxy API doesn't use 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.

No the acl data doesn't have a sa id field. we're doing a map lookup using the principal to get the corresponding sa id.

Copy link
Contributor

@mtodzo mtodzo Jul 30, 2021

Choose a reason for hiding this comment

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

@MuweiHe I commented about this below, but we should check if ACLs can only be created on a per SA basis, or if they can also be made on a per User basis.

But either way, I think you're using the integer ID to do the map lookup to get the resource ID for the service account. Since we're trying to deprecate the integer ID, we should just replace the integer ID with the resource ID in the principal column. I.e. Something like this:

Principal:

User:sa-123

Copy link
Contributor Author

@MuweiHe MuweiHe Jul 30, 2021

Choose a reason for hiding this comment

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

@mtodzo ACLs only make sense when created for a sa to my understanding 'cause saID is a required param, and admin users should already have access to resources thus don't need acls. Right now the backend service are using the numeric ID principal like 'User:123' to manage acls. So for now I can do a look up from 'User:123' to 'sa-123' and put that under the Principal column. Is that ok?

mtodzo
mtodzo previously requested changes Jul 30, 2021
Copy link
Contributor

@mtodzo mtodzo left a comment

Choose a reason for hiding this comment

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

We should update the --service-account flag as well to be --principal. Also, we should figure out whether ACLs can be configured for users (see #929 (comment))

@MuweiHe
Copy link
Contributor Author

MuweiHe commented Jul 30, 2021

We should update the --service-account flag as well to be --principal. Also, we should figure out whether ACLs can be configured for users (see #929 (comment))

like in {"Principal", "ServiceAccountId", "Permission", "Operation", "ResourceType", "ResourceName", "PatternType"} The first column is like 'User: 1234' the second 'sa-12345'. So do we remove the first column and rename the second to be principal?

@mtodzo
Copy link
Contributor

mtodzo commented Jul 30, 2021

We should update the --service-account flag as well to be --principal. Also, we should figure out whether ACLs can be configured for users (see #929 (comment))

like in {"Principal", "ServiceAccountId", "Permission", "Operation", "ResourceType", "ResourceName", "PatternType"} The first column is like 'User: 1234' the second 'sa-12345'. So do we remove the first column and rename the second to be principal?

Yeah, except it should probably include the principal prefix, so it would be User:sa-12345 ... maybe check with Ethan, but yeah the 1234 in User:1234 is the numeric ID that we don't want to show.

@MuweiHe MuweiHe force-pushed the CLI-979-2.0 branch 2 times, most recently from 8abee17 to 9167a84 Compare July 30, 2021 23:05
@MuweiHe MuweiHe requested a review from mtodzo July 30, 2021 23:11
test/fixtures/output/kafka/kafka-acls-list.golden Outdated Show resolved Hide resolved
internal/pkg/acl/acl.go Outdated Show resolved Hide resolved
Copy link
Contributor

@DABH DABH left a comment

Choose a reason for hiding this comment

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

I left a question, but, this looks good to me overall. I would like @mtodzo to give the final +1 though since he is most familiar with the REST interface. Thank you!

internal/pkg/sso/auth_state.go Outdated Show resolved Hide resolved
Copy link
Contributor

@mtodzo mtodzo left a comment

Choose a reason for hiding this comment

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

few comments, but after those looks good!

internal/cmd/kafka/command_acl.go Outdated Show resolved Hide resolved
internal/cmd/kafka/command_acl.go Outdated Show resolved Hide resolved
internal/pkg/acl/acl.go Outdated Show resolved Hide resolved
internal/pkg/acl/acl.go Outdated Show resolved Hide resolved
internal/pkg/acl/acl.go Outdated Show resolved Hide resolved
User:0 | ALLOW | DESCRIBE | TOPIC | 'test-topic' | LITERAL
Principal | Permission | Operation | ResourceType | ResourceName | PatternType
+-----------+------------+-----------+--------------+--------------+-------------+
User: | ALLOW | READ | TOPIC | 'test-topic' | LITERAL
Copy link
Contributor

Choose a reason for hiding this comment

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

is this expected to be empty? User:

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This file is not used anywhere... I might have changed it to be safe.

Copy link
Contributor

Choose a reason for hiding this comment

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

Should we delete it if it's not used anywhere?

@mtodzo mtodzo dismissed their stale review September 7, 2021 16:42

changes addressed

@mtodzo mtodzo self-requested a review September 9, 2021 04:06
Copy link
Contributor

@mtodzo mtodzo left a comment

Choose a reason for hiding this comment

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

lgtm!

@MuweiHe MuweiHe merged commit 0d970d0 into 2.0 Sep 9, 2021
@MuweiHe MuweiHe deleted the CLI-979-2.0 branch September 9, 2021 20:10
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.

4 participants