add guidance about avoiding cross namespace references from namespaced resource #5455
Conversation
k8s-ci-robot
added
cncf-cla: yes
k8s-ci-robot
added
the
sig/architecture
| @@ -876,6 +876,20 @@ kind `Foo` by just the name (within the current namespace, if a namespaced | |||
| resource), or should be called `fooRef`, and should contain a subset of the | |||
| fields of the `ObjectReference` type. | |||
|
|
|||
| Object references on a namespaced type should usually refer only to objects in | |||
| the same namespace. Because namespaces are a security boundary, cross namespace | |||
| references can have unexpected impacts, including: | |||
There was a problem hiding this comment.
Does 'usually' in this case imply that there may be some cases in which it's okay for a reference to span namespaces? Or is this intended to account for cases such as a reference from a namespaced resource to a cluster scoped resource (e.g. a Pod's nodeName)?
There was a problem hiding this comment.
Does 'usually' in this case imply that there may be some cases in which it's okay for a reference to span namespaces? Or is this intended to account for cases such as a reference from a namespaced resource to a cluster scoped resource (e.g. a Pod's
nodeName)?
It is to account for cases like a double-opt-in between namespaces. I'm not prepared to say that I know so much that this is a never-ever, but the bar is fairly high.
| able to express "give me that one over there" is dangerous across namespaces without addition work for permission checks | ||
| or opt-in's from both involved namespaces. | ||
| 3. referential integrity problems that one party cannot solve. Referencing namespace/B from namespace/A doesn't imply the | ||
| power to control the other namespace. This means that you can refer to a thing you cannot create or update. |
There was a problem hiding this comment.
Points two and three are interesting because on one hand they intuitively make sense to me, but on the other hand they seem like they could occur within a namespace too. If you consider the below reference...
apiVersion: example.org/v1
kind: CoolSource
metadata:
namespace: a
name: verycool
spec:
targetRef:
apiVersion: example.org/v1
kind: CoolTarget
name: evencoolertargetThere's no guarantee that the author of the CoolSource has RBAC access to view or otherwise interact with a CoolTarget within the same namespace. That said, it does seem less likely (but obviously not impossible) that the author would have any kind of RBAC access to another namespace.
There was a problem hiding this comment.
There's no guarantee that the author of the
CoolSourcehas RBAC access to view or otherwise interact with aCoolTargetwithin the same namespace. That said, it does seem less likely (but obviously not impossible) that the author would have any kind of RBAC access to another namespace.
There is no guarantee, but it is highly likely that inside of a single namespace the resources are at least viewable and likely edit-able.
| 1. leaking information about one namespace into another namespace. It's natural to place status messages or even bits of | ||
| content about the referenced object in the original. This is a problem across namespaces. | ||
| 2. potential invasions into other namespaces. Often references give access to a piece of referred information, so being | ||
| able to express "give me that one over there" is dangerous across namespaces without addition work for permission checks |
There was a problem hiding this comment.
| able to express "give me that one over there" is dangerous across namespaces without addition work for permission checks | |
| able to express "give me that one over there" is dangerous across namespaces without additional work for permission checks |
| Object references on a namespaced type should usually refer only to objects in | ||
| the same namespace. Because namespaces are a security boundary, cross namespace |
There was a problem hiding this comment.
If we're going to be squishy with a "usually", should we be clearer in saying built-in types and ownerReferences don't support cross-namespace references, and if a non-built-in type chooses to, it should do double opt-in or permission checks to prevent these problems?
Is it worth explicitly saying here that object references on built-in kubernetes types and in ownerReferences do not support cross namespace references
There was a problem hiding this comment.
If we're going to be squishy with a "usually", should we be clearer in saying built-in types and ownerReferences don't support cross-namespace references, and if a non-built-in type chooses to, it should do double opt-in or permission checks to prevent these problems?
Is it worth explicitly saying here that object references on built-in kubernetes types and in ownerReferences do not support cross namespace references
updated
deads2k
force-pushed
the
objectref-guidance
branch
from
93ef4db to
86550d6
Compare
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, liggitt The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
As per kubernetes/community#5455, it is not a reccomended pattern.
As per kubernetes/community#5455, it is not a recommended pattern.
As per kubernetes/community#5455, it is not a recommended pattern.
As per kubernetes/community#5455, it is not a recommended pattern.
As per kubernetes/community#5455, it is not a recommended pattern.
As per kubernetes/community#5455, it is not a recommended pattern.
This is response to a question on slack. Having cross-namespace references in an API is a risky thing to do and this clarifies why.