Mitigation plan for the issue 'No Manage Ns Secrets'

[thejaswiniguduru]

I'm currently utilizing the Kubernetes Nginx Ingress Controller in Azure Kubernetes Service. In order to meet the security requirements, I need to drop the resource secrets from kind-role for name: 'ngnix-ingress' and name: 'ingress-nginx-admission'.

Please suggest on possible in-stability on removing 'secret' resource for the 'kind-Role' in 'ngnix-ingress' and 'ingress-nginx-admission' since' InfoSecurity team detected possible vulnerability or information breach as shown in the below link.
https://avd.aquasec.com/misconfig/kubernetes/general/avd-ksv-0113/

As is Setting:
`apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.9.3
name: ingress-nginx
namespace: var_namespace
rules:

• apiGroups:
  • ""
    resources:
  • namespaces
    verbs:
  • get
• apiGroups:
  • ""
    resources:
  • configmaps
  • pods
  • secrets
  • endpoints
    verbs:
  • get
  • list
  • watch`

`apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.9.3
name: ingress-nginx-admission
namespace: var_namespace
rules:

• apiGroups:
  • ""
    resources:
  • secrets
    verbs:
  • get
  • create`

To be Setting:
`apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.9.3
name: ingress-nginx
namespace: var_namespace
rules:

• apiGroups:
  • ""
    resources:
  • namespaces
    verbs:
  • get
• apiGroups:
  • ""
    resources:
  • configmaps
  • pods
  • endpoints
    verbs:
  • get
  • list
  • watch`

`apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.9.3
name: ingress-nginx-admission
namespace: var_namespace
rules:

• apiGroups:
  • ""
    resources:
    verbs:
  • get
  • create`

Unfortunately when i drop the resource secrets from kind-role for name: 'ngnix-ingress' and name: 'ingress-nginx-admission', pods are running but getting the error as below.

Logs of the pods ingress-nginx-admission-create and ingress-nginx-admission-patch are as follows:

W0221 14:31:48.141403 1 client_config.go:618] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.
{"err":"secrets "ingress-nginx-admission" is forbidden: User "system:serviceaccount:ns-app-dp-ingress-comp-dev:ingress-nginx-admission" cannot get resource "secrets" in API group "" in the namespace "ns-app-dp-ingress-comp-dev": RBAC: role.rbac.authorization.k8s.io "ingress-nginx-admission" not found\nAzure does not have opinion for this user.","level":"fatal","msg":"error getting secret","source":"k8s/k8s.go:232","time":"2024-02-21T14:31:48Z"}

Logs of ingress controller as follows:

,SelfLink:,UID:,ResourceVersion:,Generation:0,CreationTimestamp:0001-01-01 00:00:00 +0000 UTC,DeletionTimestamp:,DeletionGracePeriodSeconds:nil,Labels:map[string]string{},Annotations:map[string]string{},OwnerReferences:[]OwnerReference{},Finalizers:[],ManagedFields:[]ManagedFieldsEntry{},}"
E0221 14:30:56.559452 7 queue.go:131] "requeuing" err="services "ingress-nginx-controller" not found" key="&ObjectMeta{Name:sync status,GenerateName:,Namespace:,SelfLink:,UID:,ResourceVersion:,Generation:0,CreationTimestamp:0001-01-01 00:00:00 +0000 UTC,DeletionTimestamp:,DeletionGracePeriodSeconds:nil,Labels:map[string]string{},Annotations:map[string]string{},OwnerReferences:[]OwnerReference{},Finalizers:[],ManagedFields:[]ManagedFieldsEntry{},}"
E0221 14:30:56.724518 7 queue.go:131] "requeuing" err="services "ingress-nginx-controller" not found" key="&ObjectMeta{Name:sync status,GenerateName:,Namespace:,SelfLink:,UID:,ResourceVersion:,Generation:0,CreationTimestamp:0001-01-01 00:00:00 +0000 UTC,DeletionTimestamp:,DeletionGracePeriodSeconds:nil,Labels:map[string]string{},Annotations:map[string]string{},OwnerReferences:[]OwnerReference{},Finalizers:[],ManagedFields:[]ManagedFieldsEntry{},}"

The following Kubernetes Ingress Controller Manifest file is used in my project.
https://github.com/kubernetes/ingress-nginx/blob/main/deploy/static/provider/baremetal/deploy.yaml

[k8s-ci-robot]

This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[longwuyuan]

Unlike many other apps, the ingress controller needs to work with the TLS field of a ingress resource, in any namespace. So that permission is a core requirement and can not be removed . If a bad actor has access to your ingress controller, then you have more serious security problems and not just that permission.

…

On Wed, 21 Feb, 2024, 8:17 pm Kubernetes Prow Robot, < ***@***.***> wrote: This issue is currently awaiting triage. If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance. The triage/accepted label can be added by org members by writing /triage accepted in a comment. Instructions for interacting with me using PR comments are available here <https://git.k8s.io/community/contributors/guide/pull-requests.md>. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra <https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:> repository. — Reply to this email directly, view it on GitHub <#11004 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGZVWT7YNWBYS2PGYADURTYUYCGXAVCNFSM6AAAAABDTGASZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJWHAYTEOJVGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[longwuyuan]

/remove-kind bug

…

On Wed, 21 Feb, 2024, 8:41 pm Yuan, ***@***.***> wrote: Unlike many other apps, the ingress controller needs to work with the TLS field of a ingress resource, in any namespace. So that permission is a core requirement and can not be removed . If a bad actor has access to your ingress controller, then you have more serious security problems and not just that permission. On Wed, 21 Feb, 2024, 8:17 pm Kubernetes Prow Robot, < ***@***.***> wrote: > This issue is currently awaiting triage. > > If Ingress contributors determines this is a relevant issue, they will > accept it by applying the triage/accepted label and provide further > guidance. > > The triage/accepted label can be added by org members by writing /triage > accepted in a comment. > > Instructions for interacting with me using PR comments are available here > <https://git.k8s.io/community/contributors/guide/pull-requests.md>. If > you have questions or suggestions related to my behavior, please file an > issue against the kubernetes/test-infra > <https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:> > repository. > > — > Reply to this email directly, view it on GitHub > <#11004 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABGZVWT7YNWBYS2PGYADURTYUYCGXAVCNFSM6AAAAABDTGASZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJWHAYTEOJVGA> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

[strongjz]

The webhook generates a certificate for use and stores it in a secret. Any TLS secret for an ingress object is stored in a secret, those ingress object can be in any namespace, the ingress controller needs access to secrets.

/close