An issue with changing permissions on PVC from within k8s pod. | NetApp | Page 1

craggy raven Mar 10, 2023, 2:55 AM

#

pod is running with

securityContext:
  readOnlyRootFilesystem: false
  runAsGroup: 0
  runAsNonRoot: false
  runAsUser: 0

and then during pod startup process we create user 1000 with 1000 group and chmod mounted PVC.
it works with k8s 1.23 works, and it changes actual volume permissions:

                                    User ID: 1000
                                   Group ID: 1000
                             Security Style: unix
                           UNIX Permissions: ---rwxr-x---

but on 1.24 chmod failing and permissions stay the same:

                                    User ID: 0
                                   Group ID: 0
                             Security Style: unix
                           UNIX Permissions: ---rwxrwxrwx

Any idea where issue might be?

#

in this case, when chmod does not work , Tridend mount PVC as 65534/65534 (nobody/nogroup). it should really be root(0)/root(0)

rugged sparrow Mar 10, 2023, 1:22 PM

#

Same backend? Same SVM? Same export policy on storage?

craggy raven Mar 10, 2023, 1:38 PM

#

same exact copy of component versions deployed via automated FluxCD pipeline (Trident operators, Trident Backend settings, PVC setting, Applications.) But different NetApp filers and different SVM.

#

any particular SVM setting that might have a side effect on a behaviour above ?

rugged sparrow Mar 10, 2023, 2:09 PM

#

The export policy on the SVM you are using is not allowing superuser access. So the User ID 0 is now an anonymous user and the default user ID to which Anonymous Users are mapped is 65534.

craggy raven Mar 10, 2023, 2:32 PM

#

interesting, cause Export Policy is fully managed by Trident in both cases

#

autoExportPolicy: true
autoExportCIDRs: ["0.0.0.0/0", "::/0"]

rugged sparrow Mar 10, 2023, 3:40 PM

#

You're going to have to check it from the storage side.

craggy raven Mar 10, 2023, 5:23 PM

#

would you mind to be more specific? check what on NetApp side? Export policy? it onlt have a list ingress rules. something like:

#

qa03scl-k8s-1::> export-policy rule show -policyname trident-e9c56219-4ed6-426d-87c2-d7f4d668a980
Policy Rule Access Client RO
Vserver Name Index Protocol Match Rule

qa03scl-k8s-1
trident-e9c56219-4ed6-426d-87c2-d7f4d668a980
1 nfs 10.4.232.197, any
10.42.1.0,172.17.0.1
qa03scl-k8s-1
trident-e9c56219-4ed6-426d-87c2-d7f4d668a980
2 nfs 10.4.232.96, any
10.42.2.0,172.17.0.1
qa03scl-k8s-1
trident-e9c56219-4ed6-426d-87c2-d7f4d668a980
3 nfs 10.4.232.26, any
10.42.0.0,172.17.0.1
3 entries were displayed.

#

this?

#

pd07-pphx01-production-1::> export-policy rule show trident-9c401eee-5307-465a-82be-574e4df1a0f8 -ruleindex 1

                            Policy Name: trident-9c401eee-5307-465a-82be-574e4df1a0f8
                             Rule Index: 1
                        Access Protocol: nfs

List of Client Match Hostnames, IP Addresses, Netgroups, or Domains: 10.42.4.0,10.49.70.18,172.17.0.1
RO Access Rule: any
RW Access Rule: any
User ID To Which Anonymous Users Are Mapped: 65534
Superuser Security Types: any
Honor SetUID Bits in SETATTR: true
Allow Creation of Devices: true

rugged sparrow Mar 10, 2023, 7:20 PM

#

Part of the problem is that the output changes in ONTAP from version to version, which is why I hadn't been giving specific examples.

The second one you posted looks correct as you can see the "Superuser Security Types: any" line. This means that the root user (userid 0) will be allowed to com in as root (id 0) and not as nobody (id 65534).

The first output you listed does not show enough information. Try the following command to see if the superuser is set to "any" or something else:
export-policy rule show -policyname trident-e9c56219-4ed6-426d-87c2-d7f4d668a980 -fields superuser

#An issue with changing permissions on PVC from within k8s pod.