A pod label is not a policy

A label is a key on the object

A label such as env=lab is metadata on the pod. It is a string the object carries. It does not, by itself, name a NetworkPolicy, a Pod Security label on the namespace, or a rule that selected this pod.

Several pods can share a label. Sharing the key does not mean they share a control you have not opened.

A policy is another object

A control lives on its own object: a policy, a namespace label, or an admission config. You can say it selects this pod only after you saved that object and its selector matches the label you quoted.

If that object is not in the note, write “policy not read.” Do not promote the pod label into a default-deny or a restricted profile.

Keep the key and the control apart

File the pod namespace, the name, and the labels you are citing. File a policy only with its name and the selector you actually read. A sentence about enforcement has to point at the policy, not at the pod label alone.

Lab: env=lab read as a restriction

Pod lab-web in team-a shows label env=lab. No policy object was saved. A draft says the namespace is default-deny and the pod is restricted because of that label.

The note quotes env=lab as a label on the pod. Policy: not read. Default-deny and restricted are removed. Those words would need the policy or namespace object, which this paste does not have.

namespace: team-a
pod: lab-web
label: env=lab
policy object: not read
write: the label only
not: default-deny, and not restricted