-
Notifications
You must be signed in to change notification settings - Fork 23
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
Comments
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
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:
oc create namespace test-quay-bridge-1
oc apply -f an-imagestream-in-that-namespace.yaml
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:
²
³
The text was updated successfully, but these errors were encountered: