Change:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be In , document that a wildcard value for a resource or a resource name means “any”. Why is this needed Although the use of ` as a wildcard is common in Kubernetes, there are several mechanisms and readers might want to know which to use. Comments The API reference at also doesn't mention that is a wildcard here. /sig auth /language en
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. &lt;detailsIn response to : /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. &lt;/details
&amp;mdash; but you can't grant for all subresources, eg .
Can u please elaborate what we have to do in this.
I'll defer to you to handle. Otherwise I can take a crack at it.
please verify the following: Maybe in the section, we could add something like: You can also use wildcards [resourcesresourceNamespods//loglog subresource for all pods. Modify the upstream file at The API reference docs are generated from the upstream, so changes to the docs mean modifying the comments in the upstream file and creating a PR.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/assign /remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /lifecycle frozen
/triage accepted
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on /unassign
/assign
Note the API reference was updated for v1.22 so I will just update the RBAC doc.

Discussion:
For example, `kubectl get configmaps --field-selector=metadata.name=my-configmap` {{< /note >}} <ins> Rather than referring to individual `resources` and `verbs` you can use the wildcard `*` symbol to refer to all such objects. For `nonResourceURLs` you can use the wildcard `*` symbol as a suffix glob match and for `apiGroups` and `resourceNames` an empty set means that everything is allowed. Here is an example that allows access to perform any current and future action on all current and future resources (note, this is similar to the built-in `cluster-admin` role). ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: example.com-superuser  # DO NOT USE THIS ROLE, IT IS JUST AN EXAMPLE rules: - apiGroups: ["example.com"] resources: ["*"] verbs: ["*"] ``` {{< caution >}} Using wildcards in resource and verb entries could result in overly permissive access being granted to sensitive resources. For instance, if a new resource type is added, or a new subresource is added, or a new custom verb is checked, the wildcard entry automatically grants access, which may be undesirable. The [principle of least privilege](/docs/concepts/security/rbac-good-practices/#least-privilege) should be employed, using specific resources and verbs to ensure only the permissions required for the workload to function correctly are applied. {{< /caution >}} </ins> ### Aggregated ClusterRoles