Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate kubernetes-ro service #4567

Closed
erictune opened this issue Feb 18, 2015 · 18 comments · Fixed by #8155
Closed

Deprecate kubernetes-ro service #4567

erictune opened this issue Feb 18, 2015 · 18 comments · Fixed by #8155
Labels
area/security kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Milestone

Comments

@erictune
Copy link
Member

Now that the "secrets" type has been merged, and we have namespaces, I don't think it often makes sense to give blanket readonly access to objects. So, lets deprecated it.

I don't know that we want to rip it out all in one go.
Nothing is using the kubernetes-ro service as far as I can see from searching the codebase, however some customers might depend on it, and maybe openshift does. For GKE, I think we'd like it gone. So, lets add a flag to the master that disables its creation. If a customer needs it we can tell them how to get it back, but it will discourage new uses.

Once service-accounts land, we can give people that need it a way to automatically generate policy and credentials for things in pods. Then we can delete kubernetes-ro it altogether.

@yujuhong yujuhong added kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. team/master labels Feb 18, 2015
@derekwaynecarr
Copy link
Member

OpenShift is most interested in the kubernetes service. Is that going away on GKE? I actually plan to use that to support running OpenShift as a pod on Kubernetes.

Sent from my iPhone

On Feb 18, 2015, at 6:27 PM, Eric Tune notifications@github.com wrote:

Now that the "secrets" type has been merged, and we have namespaces, I don't think it often makes sense to give blanket readonly access to objects. So, lets deprecated it.

I don't know that we want to rip it out all in one go.
Nothing is using the kubernetes-ro service as far as I can see from searching the codebase, however some customers might depend on it, and maybe openshift does. For GKE, I think we'd like it gone. So, lets add a flag to the master that disables its creation. If a customer needs it we can tell them how to get it back, but it will discourage new uses.

Once service-accounts land, we can give people that need it a way to automatically generate policy and credentials for things in pods. Then we can delete kubernetes-ro it altogether.


Reply to this email directly or view it on GitHub.

@lavalamp
Copy link
Member

I think it is used by third parties-- isn't that the way our SkyDNS pod knows where to get the list of things to populate DNS with?

@vmarmol
Copy link
Contributor

vmarmol commented Feb 19, 2015

Heapster uses the RO service to get information about running things
On Feb 18, 2015 4:23 PM, "Daniel Smith" notifications@github.com wrote:

I think it is used by third parties-- isn't that the way our SkyDNS pod
knows where to get the list of things to populate DNS with?


Reply to this email directly or view it on GitHub
#4567 (comment)
.

@thockin
Copy link
Member

thockin commented Feb 19, 2015

DNS uses it. I sort of like that it is automatically rate limited, but I
also have not looked at the secrets stuff yet.

I will go with the flow, but please don't break DNS.
On Feb 18, 2015 6:00 PM, "Victor Marmol" notifications@github.com wrote:

Heapster uses the RO service to get information about running things
On Feb 18, 2015 4:23 PM, "Daniel Smith" notifications@github.com wrote:

I think it is used by third parties-- isn't that the way our SkyDNS pod
knows where to get the list of things to populate DNS with?

Reply to this email directly or view it on GitHub
<
#4567 (comment)

.

Reply to this email directly or view it on GitHub
#4567 (comment)
.

@erictune
Copy link
Member Author

@derekwaynecarr @lavalamp @thockin @vmarmol
We aren't going to break the existing use cases. They will be grandfathered in until we have the ability to automatically distribute credentials to pods. Then each existing use case will be lovingly and tenderly migrated to the kubernetes service.

@thockin
yes rate limiting is nice. we should have it for the kubernetes service.

@erictune
Copy link
Member Author

@derekwaynecarr
no, GKE does not want to get rid of kubernetes service. It wants to get rid of the insecure endpoint on the apiserver.

@erictune
Copy link
Member Author

#5921

@erictune
Copy link
Member Author

#5917

@erictune erictune added priority/backlog Higher priority than priority/awaiting-more-evidence. area/hosting and removed priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. labels Mar 25, 2015
@erictune erictune added this to the v1.0 milestone Mar 25, 2015
@davidopp davidopp added priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. and removed priority/backlog Higher priority than priority/awaiting-more-evidence. labels Apr 15, 2015
@davidopp
Copy link
Member

@erictune can you confirm that deprecating kubernetes-ro is needed for v1.0 (as opposed to the other issues you mentioned, and this one being optional for 1.0)?

@davidopp davidopp added priority/backlog Higher priority than priority/awaiting-more-evidence. status/triaged and removed priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. labels Apr 15, 2015
@erictune
Copy link
Member Author

This is not needed for 1.0, but the other two are. Fixing labels.

@erictune erictune modified the milestone: v1.0 Apr 17, 2015
@erictune
Copy link
Member Author

thinking about this more, this is needed for v1.

@lavalamp lavalamp added priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. and removed priority/backlog Higher priority than priority/awaiting-more-evidence. labels Apr 27, 2015
@davidopp
Copy link
Member

@erictune Is it OK if we assign this issue to you?

@erictune
Copy link
Member Author

Yes.

On Tue, Apr 28, 2015 at 2:54 PM, David Oppenheimer <notifications@github.com

wrote:

@erictune https://github.com/erictune Is it OK if we assign this issue
to you?


Reply to this email directly or view it on GitHub
#4567 (comment)
.

@davidopp
Copy link
Member

#7444 and #5921 are vaguely related and both marked for 1.0

@sujaymansingh
Copy link

This is a rookie question, but if the RO service is being removed, how would I access the list of services from within a container?

@roberthbailey
Copy link
Contributor

Use a service account to inject credentials and access the secure (read/write) port on the master.

@erictune
Copy link
Member Author

erictune commented Jun 5, 2015

@ sujaymansingh if you describe your client, I can suggest the best way to
access the API.

On Wed, Jun 3, 2015 at 9:16 PM, Brian Grant notifications@github.com
wrote:

Closed #4567
#4567 via #8155
#8155.


Reply to this email directly or view it on GitHub
#4567 (comment)
.

@sujaymansingh
Copy link

Hi @erictune
Sorry about the delay and thanks for reaching out!

It will mainly be python (though if it is HTTP anything could access it right?)

I'm mainly interested in a mix of python APIs (probably using flask) and standalone scripts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/security kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants