[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Tying resources to it's namespace



I opened https://github.com/kubernetes/kubernetes/issues/22438 to discuss the topic upstream.

Feel free to comment with your support or more details on your use case if needed.

Thanks,
Derek

On Wed, Mar 2, 2016 at 8:11 PM, Mateus Caruccio <mateus caruccio getupcloud com> wrote:

I guess annotation would be better suitable for oc and other clients to issue queries, doesn't it?
According to kubernets docs [1] it was designed for cases like this.

[1] https://github.com/kubernetes/kubernetes/blob/master/docs/user-guide/annotations.md

Em 02/03/2016 21:59, "Derek Carr" <decarr redhat com> escreveu:
Right... So you really need an immutable field in metadata or something similar, or an annotation field that is overridden on every create/update during admission.  

On Wednesday, March 2, 2016, Mateus Caruccio <mateus caruccio getupcloud com> wrote:
Hi Derek.
I'm building a billing backend based on container and pvc usage.
The system is going to track any interesting activity (create and delete) by watching the corresponding endpoints and store it in a document database (mongodb or similar).
One important point is that users should not be able to tamper this identifier, i.e. "oc edit pod/somepod".

--
Mateus Caruccio / Master of Puppets
GetupCloud.com - Eliminamos a Gravidade

On Wed, Mar 2, 2016 at 9:27 PM, Derek Carr <decarr redhat com> wrote:
This is not a bad idea to do in admission control as part of the namespace existence check.  

Can you elaborate a little more what you are trying to build around the feature to see if there is anything else that would be required?  I am not sure it should be an annotation versus a field in metadata, i.e. metadata.namespaceUid or something similar.

Thanks,

On Wednesday, March 2, 2016, Mateus Caruccio <mateus caruccio getupcloud com> wrote:
Is there any way to tie resources (pod, pvc, secrets, bc, etc) to it's belonging namespace without looking for namespace's lifetime?

Today I can do it by watching and recording the create and delete events for a namespace, then associate any resources to that namespace, but it doesn't seams to be the best approach. Namespaces can be destroyed and recreated by a different user with same name.

I'm looking for something like automatically adding an annotation containing namespace's uid to all resources created inside it (some sort of primary key), as soon as the resource is created.


--
Mateus Caruccio / Master of Puppets
GetupCloud.com - Eliminamos a Gravidade



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]