Does trust-manager require cluster level permissions to read secrets?

[irby]

Hello there, I'm new to trust-manager and see this as a valuable tool to facilitate synchronizing CA trust bundles for Kubernetes.

This may be a duplicate of #761

Currently, we are leveraging CA trust bundles in Kubernetes secrets and referencing the secrets in our custom issuers to establish secure, trusted connections with remote resources.

Looking over the trust-manager documentation, I have configured trust-manager with a Bundle CRD, but the synchronization does not happen unless I have a RBAC policy that provides trust-manager read access to all namespaces, not just the namespaces I'm targeting. Is this expected behavior, or am I missing a specification field somewhere?

Here's a script to reproduce:

# install cert-manager
helm install cert-manager oci://quay.io/jetstack/charts/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.19.2 \
  --set crds.enabled=true

# create a namespace for custom issuer
kubectl create namespace issuer-playground

# install trust-manager
helm install trust-manager oci://quay.io/jetstack/charts/trust-manager \
  --namespace cert-manager \
  --set secretTargets.enabled=true \
  --create-namespace \
  --wait

# create a Kubernetes secret for the trusted CA chain
kubectl create secret generic enterprise-root-ca \
  --from-file=ca.crt=trusted-chain.pem \
  --namespace=cert-manager \
  --dry-run=client -o yaml | kubectl apply -f -

kubectl apply -f - <<EOF 
apiVersion: trust.cert-manager.io/v1alpha1
kind: Bundle
metadata:
  name: issuer-ca-bundle
spec:
  sources:
  - useDefaultCAs: false
  - secret:
      name: "enterprise-root-ca"
      key: "ca.crt"
  
  target:
      secret:
         key: "ca.crt"
    
      namespaceSelector:
        matchLabels:
           issuer-ca-bundle: "enabled"
EOF

# label the namespace to allow issuer-ca-bundle to write secrets to it
kubectl label namespace issuer-playground issuer-ca-bundle=enabled

When trust-manager runs, I see the following error:

time=2026-01-16T00:56:43.353Z level=ERROR msg="Failed to watch" logger=controller-runtime/cache/UnhandledError err="failed to list *v1.PartialObjectMetadata: secrets is forbidden: User \"system:serviceaccount:cert-manager:trust-manager\" cannot list resource \"secrets\" in API group \"\" at the cluster scope" reflector=k8s.io/client-go@v0.34.3/tools/cache/reflector.go:290 type=*v1.PartialObjectMetadata

The error is pretty explicit -- trust-manager does not have the ability to list secrets at the cluster scope. The only way I see to fix this issue is create RBAC policies that grant secret read at the cluster level and permission to write secrets at the namespace level.

# create ClusterRole allowing trust-manager to read secrets at the cluster level
kubectl apply -f - <<EOF
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: trust-manager-read
  labels:
    app.kubernetes.io/name: trust-manager
rules:
- apiGroups: ["trust.cert-manager.io"]
  resources: ["bundles"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["trust.cert-manager.io"]
  resources: ["bundles/status"]
  verbs: ["patch", "update"]
- apiGroups: [""]
  resources: ["secrets", "configmaps"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "patch"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: trust-manager-read
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: trust-manager-read
subjects:
- kind: ServiceAccount
  name: trust-manager
  namespace: cert-manager
EOF


# create a Role for the issuer-playground namespace allowing trust-manager to write to secrets
kubectl apply -f - <<EOF
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: trust-manager-write
  namespace: issuer-playground # change to your namespace
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["create", "update", "patch", "delete"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: trust-manager-write
  namespace: issuer-playground  # change to your namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: trust-manager-write
subjects:
- kind: ServiceAccount
  name: trust-manager
  namespace: cert-manager
EOF

Now, after applying that RBAC rule, I'm able to sync my secret successfully to the issuer-playground namespace.

Is it necessary that trust-manager needs to have read access to secrets cluster-wide? Or am I applying the incorrect specification to the bundle? I can see the need to list namespaces to determine the labels, but it doesn't make sense why it needs cluster-level access to read secrets.

[arsenalzp]

Hello,
As far as I remember, accessing configMap and secret resources in a namespace different from the Pod’s own namespace is forbidden by default.
This is a Kubernetes restriction, not something imposed by the operator itself.

[erikgb]

If you want to use secret targets in trust-manager, trust-manager requires access to secrets cluster-wide. Kubernetes RBAC can only restrict access by the name of resources, and not labels. What you can do, is to set the list of namespaces trust-manager should have access to using this quite recent feature in trust-manager: https://github.com/cert-manager/trust-manager/blob/main/deploy/charts/trust-manager/values.yaml#L248-L250. But it's not very flexible, as you can see.

My advice is to source trust bundles from configmaps - as trust-manager does by default.

[irby]

If you want to use secret targets in trust-manager, trust-manager requires access to secrets cluster-wide. Kubernetes RBAC can only restrict access by the name of resources, and not labels. What you can do, is to set the list of namespaces trust-manager should have access to using this quite recent feature in trust-manager: https://github.com/cert-manager/trust-manager/blob/main/deploy/charts/trust-manager/values.yaml#L248-L250. But it's not very flexible, as you can see.

My advice is to source trust bundles from configmaps - as trust-manager does by default.

Hey @erikgb thank you very much. Would ConfigMap targets also require similar RBAC? Based on the documentation, I wouldn't think so but I also didn't see documentation about the RBAC policy if targeting secrets.

EDIT: I'm guessing the trust specification would reduce the need for the RBAC policies I've defined above?

[erikgb]

Cluster-wide access to secrets is granted by you supplying secretTargets.enabled=true when installing trust-manager with Helm. By default, trust-manager only has access to secrets in the trust namespace.

[irby]

Hey @erikgb thank you for your response, but I think that may be incorrect given my error indicated in the issue. While I do have secretTargets.enabled=true on my trust-manager deployment specification, it will not be able to access secrets on the cluster level until the explicit RBAC ClusterRole policy is made to allow access to those secrets, otherwise it returns an error it could not read secrets.

time=2026-01-16T00:56:43.353Z level=ERROR msg="Failed to watch" logger=controller-runtime/cache/UnhandledError err="failed to list *v1.PartialObjectMetadata: secrets is forbidden: User \"system:serviceaccount:cert-manager:trust-manager\" cannot list resource \"secrets\" in API group \"\" at the cluster scope" reflector=k8s.io/client-go@v0.34.3/tools/cache/reflector.go:290 type=*v1.PartialObjectMetadata

If I leave the deployment with the secretTargets not enabled, I just get an error message the feature is disabled:

time=2026-01-16T15:33:00.371Z level=ERROR msg="bundle has Secret targets but the feature is disabled"

The ClusterRole that's created when this feature is enabled does not have secret resources scoped:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: trust-manager
  uid: 1631d0b0-920e-430a-a758-9920ee46782c
  resourceVersion: '615'
  creationTimestamp: '2026-01-16T15:35:49Z'
  labels:
    app.kubernetes.io/instance: trust-manager
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: trust-manager
    app.kubernetes.io/version: v0.20.3
    helm.sh/chart: trust-manager-v0.20.3
  annotations:
    meta.helm.sh/release-name: trust-manager
    meta.helm.sh/release-namespace: cert-manager
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/trust-manager
spec: {}
rules:
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - trust.cert-manager.io
    resources:
      - bundles
  - verbs:
      - update
    apiGroups:
      - trust.cert-manager.io
    resources:
      - bundles/finalizers
  - verbs:
      - patch
    apiGroups:
      - trust.cert-manager.io
    resources:
      - bundles/status
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - ''
    resources:
      - namespaces
  - verbs:
      - get
      - list
      - create
      - patch
      - watch
      - delete
    apiGroups:
      - ''
    resources:
      - configmaps
  - verbs:
      - create
      - patch
    apiGroups:
      - ''
    resources:
      - events

So, I think that may be a bug if the ClusterRole does not include secrets automatically?

I did check configmap targets on my end and determined that they do behave as expected with no additional RBAC configuration. I'll update my issuer to allow for ConfigMaps to be used, as this is a feature that's been asked for. But, I did want to point out the additional RBAC configuration for secrets.

[erikgb]

Yes, you are absolutely correct! My bad! Sorry! It is also documented on the Helm value:

trust-manager/deploy/charts/trust-manager/values.yaml

Lines 142 to 146 in 4bfbf4e

	secretTargets:
	# If set to true, enable writing trust bundles to Kubernetes Secrets as a target.
	# trust-manager can only write to secrets which are explicitly allowed via either authorizedSecrets or authorizedSecretsAll.
	# Note that enabling secret targets will grant trust-manager read access to all secrets in the cluster.
	enabled: false

But in order to support secret targets, cluster-wide access to secrets is required. (Or use the value I referred to in #841 (comment), which is a less flexible setup.)

[irby]

@erikgb You are all good! I just wanted to make sure I wasn't going crazy 😆

Thank you for answering these questions!

Although, I did use app.targetNamespaces=issuer-playground with the secretTargets.enabled=true setting and notice the RBAC policy only targets configMaps and does not include secret resources. Is this a bug?

helm install trust-manager oci://quay.io/jetstack/charts/trust-manager \
  --namespace cert-manager \
  --set secretTargets.enabled=true \
  --set app.targetNamespaces={issuer-playground} \
  --create-namespace \
  --wait

ClusterRole does not include configMaps:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: trust-manager
  uid: b09bbe76-251c-453a-a352-5a5b41cd15ad
  resourceVersion: '2254'
  creationTimestamp: '2026-01-16T16:25:52Z'
  labels:
    app.kubernetes.io/instance: trust-manager
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: trust-manager
    app.kubernetes.io/version: v0.20.3
    helm.sh/chart: trust-manager-v0.20.3
  annotations:
    meta.helm.sh/release-name: trust-manager
    meta.helm.sh/release-namespace: cert-manager
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/trust-manager
spec: {}
rules:
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - trust.cert-manager.io
    resources:
      - bundles
  - verbs:
      - update
    apiGroups:
      - trust.cert-manager.io
    resources:
      - bundles/finalizers
  - verbs:
      - patch
    apiGroups:
      - trust.cert-manager.io
    resources:
      - bundles/status
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - ''
    resources:
      - namespaces

Role on cert-manager and issuer-playground have configMap permission but not secret:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: trust-manager-role
  namespace: cert-manager
  uid: 091a0d34-62ce-482c-b2b8-20f717061f85
  resourceVersion: '2257'
  creationTimestamp: '2026-01-16T16:25:52Z'
  labels:
    app.kubernetes.io/managed-by: Helm
  annotations:
    meta.helm.sh/release-name: trust-manager
    meta.helm.sh/release-namespace: cert-manager
  selfLink: >-
    /apis/rbac.authorization.k8s.io/v1/namespaces/cert-manager/roles/trust-manager-role
spec: {}
rules:
  - verbs:
      - get
      - list
      - create
      - patch
      - watch
      - delete
    apiGroups:
      - ''
    resources:
      - configmaps
  - verbs:
      - create
      - patch
    apiGroups:
      - ''
    resources:
      - events


---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: trust-manager-role
  namespace: issuer-playground
  uid: 6b40a934-a052-402e-ba13-a0ce16241fe7
  resourceVersion: '2256'
  creationTimestamp: '2026-01-16T16:25:52Z'
  labels:
    app.kubernetes.io/managed-by: Helm
  annotations:
    meta.helm.sh/release-name: trust-manager
    meta.helm.sh/release-namespace: cert-manager
  selfLink: >-
    /apis/rbac.authorization.k8s.io/v1/namespaces/issuer-playground/roles/trust-manager-role
spec: {}
rules:
  - verbs:
      - get
      - list
      - create
      - patch
      - watch
      - delete
    apiGroups:
      - ''
    resources:
      - configmaps
  - verbs:
      - create
      - patch
    apiGroups:
      - ''
    resources:
      - events