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

BUG: CRDs in 0.0.8 with Dapr 1.13.2 not configuring properly #136

Open
ryorke1 opened this issue Apr 18, 2024 · 4 comments
Open

BUG: CRDs in 0.0.8 with Dapr 1.13.2 not configuring properly #136

ryorke1 opened this issue Apr 18, 2024 · 4 comments

Comments

@ryorke1
Copy link

ryorke1 commented Apr 18, 2024

Expected Behavior

Dapr CRDs are granted access to various resources within OpenShift such as ClusterRole admin and all users of OpenShift.

Current Behavior

After deploying 1.13.2 via Dapr Operator 0.0.8, the Dapr CRDs no longer grant anyone but administrators access to the CRDs.

Possible Solution

Unknown

Steps to Reproduce

  1. Uninstall any previous version of Dapr Operator (including cleaning up all CRDs and CRs)
  2. Install Dapr Operator 0.0.8
  3. Create a new DaprInstance with the following configuration (see below)
  4. Monitors the CRDs until they are created
  5. Attempt to access the CRDs (read and write) via namespace users and ServiceAccounts
  6. Both types of accounts will receive access denied
# DaprInstance 
apiVersion: operator.dapr.io/v1alpha1
kind: DaprInstance
metadata:
  name: dapr-instance
  namespace: openshift-operators
spec:
  values:
    dapr_operator:
      livenessProbe:
        initialDelaySeconds: 10
      readinessProbe:
        initialDelaySeconds: 10
    dapr_placement:
      cluster:
        forceInMemoryLog: true
    global:
      imagePullSecrets: dapr-pull-secret
      registry: internal-repo/daprio
  chart:
    version: 1.13.2

Environment

OpenShift: RedHad OpenShift Container Platform 4.12
Dapr Operator: 0.0.8 with 1.13.2 Dapr components

Workaround

  • Cluster admins have created temporary roles for ServiceAccounts to be able to access the dapr components.
  • Cluster admins have also manually given access to namespace administrators for the various CRDs
@ryorke1
Copy link
Author

ryorke1 commented Apr 19, 2024

As a side note, this may be due to #135. I suspect with the dapr-control-plane crashing that it doesn't get a chance to complete it's work but I am not sure that matters as I would expect the dapr-operator to be creating the CRDs and publishing. Thoughts?

@lburgazzoli
Copy link
Collaborator

is the same use be able to get other CRDs ? The operator/olm does not set up any permissions for the CRDs except for itself

@ryorke1
Copy link
Author

ryorke1 commented Apr 22, 2024

Doesn't appear that it's related to #135. Now that we have stablized the dapr-control-plane, the dapr-operator doesn't seem to have configured the permissions. I am not sure if this is related to this operator or not.

@lburgazzoli
Copy link
Collaborator

lburgazzoli commented Apr 22, 2024

The operator does not set any permission, except providing a ClusterRole and ClusterRoleBinding for being able to read such CRDs and CRs. Usually, user permissions are outside the scope of the operator but if you have a case to do something different, let me know and I can try to implement it.

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