dapr / dapr/kubernetes-operator
BUG: CRDs in 0.0.8 with Dapr 1.13.2 not configuring properly
- Dominant language
- Go
- Stars
- 18
- Forks
- 6
- PR merge metrics
- No merged PRs in 30d
Description
### **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
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.