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

Bridge operator (nor Quay) doesn't apply default org permissions to repositories that it creates #109

Open
domq opened this issue Jan 26, 2024 · 0 comments

Comments

@domq
Copy link

domq commented Jan 26, 2024

It seems that Quay won't apply so-called “default” permissions to repositories created by a robot account; and quay-bridge-operator doesn't directly manipulate permissions either. Therefore, we appear to be left with a gap, whereby the only way to push and pull images to and from Quay is to manipulate permissions through the Quay UI, largely defeating the purpose of quay-bridge-operator.

Using Red Hat Quay Bridge Operator version 3.9 against OpenShift 4.13.12.

What I am trying to do vs. what happens:

  1. oc create namespace test-quay-bridge-1
    • Expected: quay-bridge-operator should (tell Quay to) create an Organization with three Robot Accounts fitted with suitable Permission Prototypes
    • Actual: ✓ (see: ¹)
  2. oc apply -f an-imagestream-in-that-namespace.yaml
    • Expected: quay-bridge-operator should (tell Quay to) create a Repository with suitable permissions for the above Robot Accounts
    • Actual: the Repository gets created indeed², but none of the aforementioned robot accounts have any rights to it³.

Now, I understand that there are workarounds that involve a number of clicks in the Quay UI by at least two different people; however, there used to be no need for that in OpenShift's internal registry (at least in version 3 that I have used).

Footnotes

¹ In Quay's Flask shell:

from data.database import (User, PermissionPrototype)
[dict(username=u.username, robot=u.robot, organization=u.organization)
      for u in User.select()
      if u.username.startswith("fsd_test-quay-bridge-1")]
[dict(who=p.delegate_user.username, what=p.role.name)
      for p in PermissionPrototype.select().join(User, on = PermissionPrototype.org)
                   .where(User.username == "fsd_test-quay-bridge-1")]

²

from data.database import Repository
Repository.select().where(Repository.name == "test-imagestream").first()

³

from data import model
[p for robot in ("fsd_test-quay-bridge-1+deployer", "fsd_test-quay-bridge-1+builder",
                         "fsd_test-quay-bridge-1+default")
    for p in model.permission.list_robot_permissions(robot)]
domq pushed a commit to epfl-si/sddc-ocp that referenced this issue Jan 26, 2024
As per quay/quay-bridge-operator#109 it seems that some amount of clicking in Quay's UI is required for “cloud build” workflows and “`docker push` from my workstation” workflows alike. Oh well.

- Enable LDAP “authentication,” which turns out to ① have little, if anything, to do with authentication, and ② gratuitously require a service account for LDAP binding, pursuant to [some golang-side nonsense](goharbor/harbor#13763 (comment))
- Broaden access to `si-quay` group in SATOSA
- Promote members of `si-quay-admin` (the LDAP group) to super-users
- Turn on `FEATURE_TEAM_SYNCING` (also from LDAP), and `FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP` (because why not?)
domq pushed a commit to epfl-si/sddc-ocp that referenced this issue Jan 27, 2024
As per quay/quay-bridge-operator#109 it seems that some amount of clicking in Quay's UI is required for “cloud build” workflows and “`docker push` from my workstation” workflows alike. Oh well.

- Enable LDAP “authentication,” which turns out to ① have little, if anything, to do with authentication, and ② gratuitously require a service account for LDAP binding, pursuant to [some golang-side nonsense](goharbor/harbor#13763 (comment))
- Broaden access to `si-quay` group in SATOSA
- Promote members of `si-quay-admin` (the LDAP group) to super-users
- Turn on `FEATURE_TEAM_SYNCING` (also from LDAP), and `FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP` (because why not?)
domq pushed a commit to epfl-si/sddc-ocp that referenced this issue Jan 29, 2024
As per quay/quay-bridge-operator#109 it seems that some amount of clicking in Quay's UI is required for “cloud build” workflows and “`docker push` from my workstation” workflows alike. Oh well.

- Enable LDAP “authentication,” which turns out to ① have little, if anything, to do with authentication, and ② gratuitously require a service account for LDAP binding, pursuant to [some golang-side nonsense](goharbor/harbor#13763 (comment))
- Broaden access to `si-quay` group in SATOSA
- Promote members of `si-quay-admin` (the LDAP group) to super-users
- Turn on `FEATURE_TEAM_SYNCING` (also from LDAP), and `FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP` (because why not?)
lelouchviesp pushed a commit to epfl-si/sddc-ocp that referenced this issue Mar 6, 2024
As per quay/quay-bridge-operator#109 it seems that some amount of clicking in Quay's UI is required for “cloud build” workflows and “`docker push` from my workstation” workflows alike. Oh well.

- Enable LDAP “authentication,” which turns out to ① have little, if anything, to do with authentication, and ② gratuitously require a service account for LDAP binding, pursuant to [some golang-side nonsense](goharbor/harbor#13763 (comment))
- Broaden access to `si-quay` group in SATOSA
- Promote members of `si-quay-admin` (the LDAP group) to super-users
- Turn on `FEATURE_TEAM_SYNCING` (also from LDAP), and `FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP` (because why not?)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant