Hello,
our application has a dependency to the cert-manager operator, so we would like to have it either installed cluster-wide, or scoped to our namespace (whichever can be achieved the fastest).
We have set up a service account in our namespace called "sf-service-account". It has the same rolebindings as my user.
Reading up on https://docs.openshift.com/container-platform/4.15/operators/admin/olm-creating-policy.html#olm-policy-scoping-operator-install_olm-creating-policy I am not sure I can perform all of the required steps to configure the service account so that we can install operators in our namespace; for instance I cannot list catalog sources already created in the cluster:
```$ kubectl get catalogSource -n openshift-marketplace
Error from server (Forbidden): catalogsources.operators.coreos.com is forbidden: User "system:serviceaccount:cloud-softwarefactory:sf-service-account" cannot list resource "catalogsources" in API group "operators.coreos.com" in the namespace "openshift-marketplace"```
Could you first configure the service account to have the proper permissions scoped to our namespace: https://docs.openshift.com/container-platform/4.15/operators/admin/olm-creating-policy.html#olm-policy-fine-grained-permissions_olm-creating-policy
Then also create the proper subscription so that we can pull cert-manager from operatorhub.io: (step 4 of https://docs.openshift.com/container-platform/4.15/operators/admin/olm-creating-policy.html#olm-policy-scoping-operator-install_olm-creating-policy )
Thanks!
Metadata Update from @arrfab: - Issue tagged with: centos-ci-infra, feature-request, high-gain, high-trouble, investigation
I guess we can easily install operator cluster-wide but we need to know which one. From OperatorHub on deployed OCP we see both : * cert-manager (provided by the cert-manager maintainers) * cert-manager Operator for Red Hat Openshift (provided by Red Hat) (see official doc )
I guess that would be the second one (really targeted at OCP)
That looks like the best choice yes. If you enable this cluster-wide then the request above about enabling the service account to install operators can be discarded.
We would simply need to have a role bound to the service account to have access to its API on our namespace - and the prometheus operator API as well while we're at it. Something like:
--- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: cloud-softwarefactory name: sf-deployer-role rules: - apiGroups: - cert-manager.io resources: - '*' verbs: - create - delete - get - list - patch - update - watch - apiGroups: - monitoring.coreos.com resources: - podmonitors - prometheusrules - prometheuses - servicemonitors verbs: - create - delete - get - list - patch - update - watch
We managed to get rid of our dependency to the cert-manager operator, so this issue can actually be closed.
The role changes to allow our service account to interact with some prometheus-operator resources is still desirable so I will open a different ticket for this one. Thanks!
Metadata Update from @mhuin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.