Messaging Topology Operator permission denied when reconciling user credentials secret #748
-
|
Hi, I've been struggling with a permissions issue for a few days so I thought I'd post here to see if anybody can help. I have a K8s cluster running on AWS EKS and the messaging topology operator is giving the following error log: {
"level": "error",
"ts": "2024-01-23T09:54:24Z",
"msg": "Reconciler error",
"controller": "user",
"controllerGroup": "rabbitmq.com",
"controllerKind": "User",
"User": {
"name": "user",
"namespace": "default"
},
"namespace": "default",
"name": "user",
"reconcileID": "7d5162d8-a0f8-4d3e-b98f-56fab80603dc",
"error": "secrets \"user-credentials\" is forbidden: User \"system:serviceaccount:rabbitmq-system:messaging-topology-operator\" cannot update resource \"secrets\" in API group \"\" in the namespace \"default\"",
"stacktrace": "sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:324\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:265\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:226"
}Cluster Operator and Messaging Topology Operator are in the rabbitmq-system namespace. They have been installed with the provided k8s manifests here and here respectively. The RabbitmqCluster has been deployed in the default namespace and is reconciled successfully from the following manifest: apiVersion: rabbitMqManifestApiVersion,
kind: "RabbitmqCluster",
metadata: {
annotations: {
"rabbitmq.com/topology-allowed-namespaces": "default",
},
name: rabbitMqClusterName,
},
spec: {
replicas: 1,
resources: {
limits: {
cpu: "100m",
memory: "0.5Gi",
},
requests: {
cpu: "100m",
memory: "0.5Gi",
},
},
},The Secret, User and Permission have the following manifest but is failing: {
apiVersion: "v1",
kind: "Secret",
metadata: {
name: "user-credentials",
},
stringData: {
password: "mypass",
username: "username",
},
type: "Opaque",
},
{
apiVersion: "rabbitmq.com/v1beta1",
kind: "User",
metadata: {
name: "username",
},
spec: {
importCredentialsSecret: {
name: "user-credentials",
},
rabbitmqClusterReference: {
name: rabbitMqClusterName,
},
},
},
{
apiVersion: "rabbitmq.com/v1beta1",
kind: "Permission",
metadata: {
name: "user-permission",
},
spec: {
permissions: {
configure: ".*",
read: ".*",
write: ".*",
},
rabbitmqClusterReference: {
name: rabbitMqClusterName,
},
user: "username",
vhost: "/",
},
},
Can anybody spot the misconfiguration? From reading the docs it seems like that role should have permission to reconcile in the default namespace and read/write secrets. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
|
This feels like a question for @Zerpet or @MirahImage 🤞 |
Beta Was this translation helpful? Give feedback.
-
|
It seems like the role is missing And the role definition: Indeed looks like it does not have permissions to messaging-topology-operator/config/rbac/role.yaml Lines 15 to 23 in 35b16b5 What version of the Topology Operator are you running? It's probably the latest, given your post, but it doesn't hurt to double check. Inspecting the image field in the |
Beta Was this translation helpful? Give feedback.
-
|
Yes I'm running latest - I did add the Side note: I'm still curious because I have seen this reconcile successfully before, without making any edits to the messaging topology operator manifest. Since then, though, I have refactored and re-built the cluster and I can't work out what changed in my configuration. |
Beta Was this translation helpful? Give feedback.
-
|
I can't reproduce the issue in our latest 1.13.0 release. I don't think the new minor changed anything significant that would resolve this specific issue. The only thing I can think of, it's if you create a Can you confirm if this is the case? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @Zerpet, you're exactly correct with this. I was creating a secret with a name clash. Renamed to |
Beta Was this translation helpful? Give feedback.
I can't reproduce the issue in our latest 1.13.0 release. I don't think the new minor changed anything significant that would resolve this specific issue.
The only thing I can think of, it's if you create a
Secretwith the same name as we would create. Our operator generates aSecretwith the name<user.metadata.name>-user-credentials. For example, if you create aSecretnamedfoo-user-credentials, and then create aUsernamedfoo, our Operator will try to create aSecretthat you have already created, and update it to set an owner reference.Can you confirm if this is the case?