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

First draft of a GitHubIdentityProvider CRD #1900

Merged
merged 3 commits into from
Apr 1, 2024

Conversation

joshuatcasey
Copy link
Member

See #1859

//
// +kubebuilder:default=Deny
// +kubebuilder:validation:Enum=Allow;Deny
AllowAllUsersToLogin GitHubAllowAllUsersToLoginSpec `json:"allowAllUsersToLogin"`
Copy link
Member

Choose a reason for hiding this comment

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

Is the naming sort of awkward that you can set a field called "AllowSomething" to have the value "Deny"? The field's name says it is about allowing something, not denying something.

Maybe name it something like AllowedUsers, to be symmetrical with AllowedOrganizations? Possible values would be something like:

  • OnlyUsersBelongingToAllowedOrganizations (the default), which also makes it clear that it relates back to the AllowedOrganizations field
  • AllUsers

Copy link
Member Author

@joshuatcasey joshuatcasey Mar 19, 2024

Choose a reason for hiding this comment

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

It's definitely a little awkward.

How about GitHubOrganizationLoginPolicy with AllowedOrganizationsOnly as the default and AllOrganizationsAllowed as the other option?

Copy link
Member

Choose a reason for hiding this comment

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

I find it confusing that those names have substrings AllowedOrganizations and OrganizationsAllowed which makes them sound as if they are the same thing at first glance.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmmm that makes sense. Let's chat tomorrow and capture the decision here.

Copy link
Member

@cfryanr cfryanr Mar 26, 2024

Choose a reason for hiding this comment

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

How about AllowedOrganizationsPolicy? That name ties it back to the AllowedOrganizations field.

We want the non-default value to emphasize the effect that it allows all GitHub users to authenticate regardless of org membership, even if they belong to no orgs. So how about enum values like OnlyUsersBelongingToSpecifiedOrgs and AllGitHubUsers.

So the settings in practice would look like:

spec:
  allowedOrganizations: [vmware-tanzu, broadcom]
  allowedOrganizationsPolicy: OnlyUsersBelongingToSpecifiedOrgs

or

spec:
  allowedOrganizations: []
  allowedOrganizationsPolicy: AllGitHubUsers

and because of the default values of the two settings, these would also be valid:

spec:
  allowedOrganizations: [vmware-tanzu, broadcom]

and

spec:
  allowedOrganizationsPolicy: AllGitHubUsers

The only configurations that allow all GitHub users must explicitly say AllGitHubUsers because it is the non-default value. Kinda verbose but hopefully very clear.

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 like it

Copy link
Member Author

Choose a reason for hiding this comment

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

Let's do this instead:

---
spec:
  client:
    secretName: foo
  allowAuthentication:
    organizations:
      policy: OnlyUsersFromAllowedOrganizations
      allowed:
      - foo
      - vmware-tanzu
      - Broadcom
    personalAccessTokens:
      fineGrained: true
---
spec:
  client:
    secretName: foo
  allowAuthentication:
    organizations:
      policy: AllGitHubUsers
    personalAccessTokens:
      classic: true

Copy link

codecov bot commented Mar 19, 2024

Codecov Report

Attention: Patch coverage is 0.51948% with 383 lines in your changes are missing coverage. Please review.

Project coverage is 38.24%. Comparing base (146e61e) to head (42dd8d1).
Report is 2 commits behind head on github_identity_provider.

Files Patch % Lines
...s/supervisor/idp/v1alpha1/zz_generated.deepcopy.go 0.00% 153 Missing ⚠️
...ioned/typed/idp/v1alpha1/githubidentityprovider.go 0.00% 107 Missing ⚠️
...d/idp/v1alpha1/fake/fake_githubidentityprovider.go 0.00% 71 Missing ⚠️
...sor/listers/idp/v1alpha1/githubidentityprovider.go 0.00% 23 Missing ⚠️
...nalversions/idp/v1alpha1/githubidentityprovider.go 0.00% 21 Missing ⚠️
...rsioned/typed/idp/v1alpha1/fake/fake_idp_client.go 0.00% 2 Missing ⚠️
...ientset/versioned/typed/idp/v1alpha1/idp_client.go 0.00% 2 Missing ⚠️
...t/supervisor/informers/externalversions/generic.go 0.00% 2 Missing ⚠️
...formers/externalversions/idp/v1alpha1/interface.go 0.00% 2 Missing ⚠️
Additional details and impacted files
@@                     Coverage Diff                      @@
##           github_identity_provider    #1900      +/-   ##
============================================================
- Coverage                     38.56%   38.24%   -0.33%     
============================================================
  Files                           350      354       +4     
  Lines                         44514    44899     +385     
============================================================
+ Hits                          17169    17173       +4     
- Misses                        26831    27212     +381     
  Partials                        514      514              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@joshuatcasey joshuatcasey force-pushed the jtc/github_idp_crd branch 4 times, most recently from 9af03e1 to 400f721 Compare March 21, 2024 20:41
@joshuatcasey joshuatcasey force-pushed the jtc/github_idp_crd branch 2 times, most recently from db52f0a to ebfe439 Compare March 25, 2024 21:08
@benjaminapetersen
Copy link
Member

Noting we can now rebase this on main.

@joshuatcasey joshuatcasey marked this pull request as ready for review March 27, 2024 17:26
@joshuatcasey joshuatcasey force-pushed the jtc/github_idp_crd branch 2 times, most recently from abccc26 to c759147 Compare March 28, 2024 03:20
type GitHubUsernameAttribute string

const (
// GitHubUsernameID specifies using the `id` attribute from the GitHub user as the downstream username.
Copy link
Member

Choose a reason for hiding this comment

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

Maybe try to avoid using the term "downstream" in all the comments?

…pp-and-ytt-enhancements

Revise log level instructions for kapp and kubectl in docs
Copy link
Member

@benjaminapetersen benjaminapetersen left a comment

Choose a reason for hiding this comment

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

LGTM, I tend to agree with dropping the simple CEL validations since we have to do more sophisticated in the controller anyway. 👍

@benjaminapetersen benjaminapetersen merged commit 6ac11a5 into github_identity_provider Apr 1, 2024
33 checks passed
@benjaminapetersen benjaminapetersen deleted the jtc/github_idp_crd branch April 1, 2024 21:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants