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

multi-tenant env support (weblogic-kubernetes-operator:4.2.8) #5114

Open
Krishnamotive opened this issue Oct 14, 2024 · 5 comments
Open

multi-tenant env support (weblogic-kubernetes-operator:4.2.8) #5114

Krishnamotive opened this issue Oct 14, 2024 · 5 comments

Comments

@Krishnamotive
Copy link

I am trying to deploy web-logic operator weblogic-kubernetes-operator:4.2.8 on OCP 4.16 multi-tenant env with dedicated domainNamespaceSelectionStrategy. However some roles like weblogic-operator-role , weblogic-operator-general fails RBAC permission issues.
Do we need to follow any specific guidelines for this multi-tenant type installation?
Also, do we need to add any namespace based custom roles to achieve this in multi-tenant env before proceeding installation?

@rjeberhard
Copy link
Member

@Krishnamotive, with the 3.x version of the operator, it was only required that someone with sufficient cluster privileges install the CRD document and then the rest of the installation could be done in a single namespace using the dedicated mode, as you described.

However, the 4.x operator added a schema conversion webhook to assist customers with upgrading from the v8 version of the domain resource schema to the v9 version and the new v1 cluster resource. Since we were only very rarely hearing requests for support of multitenant cluster environments, we elected to have the CRD always be installed by the endpoint serving the schema conversion webhook.

You can achieve something like the 3.x dedicated mode by having someone with sufficient cluster privileges install the webhook endpoint using the webhookOnly option. Then, you could install one or more operator instances in dedicated namespaces using the selection strategy and the operatorOnly option.

We are working on an enhancement that would allow you to skip installing the schema conversion webhook entirely. When this enhancement is available, we would have restored the 3.x behavior of just requiring the installation of the CRD documents (with a kubectl create -f) prior to a dedicated mode install of the operator.

Looping in @mriccell, who is our product manager.

@Krishnamotive
Copy link
Author

Thanks @rjeberhard for your prompt response.
Do you have any timelines for the enhancement of this?

@rjeberhard
Copy link
Member

The enhancement will be available in the next few weeks to about a month. I can't yet give you a better estimate because most of the WebLogic team is focused on completing the next version of the product (WebLogic 14.1.2)

@Krishnamotive
Copy link
Author

@rjeberhard ,

I would like to inquire if it's possible to create namespace-specific RBAC roles separately and then bind them to the service account (using admin privileges for this step). Once created, we could use the following options, for example:

--set rbac.enabled=false --set serviceAccountName=weblogic-operator-sa.

I looked through the charts/templates but couldn't find an option to disable RBAC. Could you please confirm if the above approach is feasible?

@rjeberhard
Copy link
Member

I'm hoping that we don't need an additional option. We already have enableClusterRoleBinding that is designed to select between the creation of ClusterRoles, which have cluster-wide scope, versus creating Roles in each managed namespace.

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

No branches or pull requests

2 participants