search

30x / project-management

Tasks not specific to a given project, exploratory stuff and project management
0 stars 0 forks source link

Enrober and Build Service are not secured #124

Closed mpnally closed 8 years ago

mpnally commented 8 years ago

Currently there is no key protecting either the "Shipyard" namespace in which the build service runs or the "Apigee" namespace in which Enrober runs. This means that anyone on the cluster can send messages to these services without protection. This has to be changed before beta. The simplest fix seems to me to be the following:

It is possible to separate Enrober from the build service in different namespaces, but this makes key management a bit more complex. Either both namespaces have to have the same key, or the Edge proxy has to have both keys and juggle which key to use according to the path, which is a mess (Enrober would need the key for the build service namespace too).

whitlockjc commented 8 years ago

Locking down external traffic would be as simple as adding the public API Key secret to the apigee namespace and updating the Edge proxy to set the header appropriately. We do not want to set a private API Key secret because the SSO Proxy is unable to juggle changing the API Keys after it authenticates the user and proxies to the private proxy. This should be enough because we should be using network policies to lock down traffic from other namespaces reaching the non-router pods. Thoughts?

mpnally commented 8 years ago

I think Enrober has to access the Build Service. Node applications in other namespaces must not be able to. How can that work without a private key?

Martin

On Thu, Aug 11, 2016 at 2:34 PM, Jeremy Whitlock notifications@github.com wrote:

Locking down external traffic would be as simple as adding the public API Key secret to the apigee namespace and updating the Edge proxy to set the header appropriately. We do not want to set a private API Key secret because the SSO Proxy is unable to juggle changing the API Keys after it authenticates the user and proxies to the private proxy. This should be enough because we should be using network policies to lock down traffic from other namespaces reaching the non-router pods. Thoughts?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/30x/project-management/issues/124#issuecomment-239300067, or mute the thread https://github.com/notifications/unsubscribe-auth/ACoA6jn2WvptTS7mUYQb4He9iVW1CrQ6ks5qe5V0gaJpZM4Jhb21 .

mpnally commented 8 years ago

P.S. I didn't understand what the problem is with SSO proxy and private keys.

Martin

On Thu, Aug 11, 2016 at 3:05 PM, Martin Nally mnally@apigee.com wrote:

I think Enrober has to access the Build Service. Node applications in other namespaces must not be able to. How can that work without a private key?

Martin

On Thu, Aug 11, 2016 at 2:34 PM, Jeremy Whitlock <notifications@github.com

wrote:

Locking down external traffic would be as simple as adding the public API Key secret to the apigee namespace and updating the Edge proxy to set the header appropriately. We do not want to set a private API Key secret because the SSO Proxy is unable to juggle changing the API Keys after it authenticates the user and proxies to the private proxy. This should be enough because we should be using network policies to lock down traffic from other namespaces reaching the non-router pods. Thoughts?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/30x/project-management/issues/124#issuecomment-239300067, or mute the thread https://github.com/notifications/unsubscribe-auth/ACoA6jn2WvptTS7mUYQb4He9iVW1CrQ6ks5qe5V0gaJpZM4Jhb21 .

jbowen93 commented 8 years ago

Both services are now secured. However at this time we are using the same public and private routing keys for both the apigee and shipyard namespaces. Still need to resolve the issue of the SSO proxy being unable to juggle keys for public/private routing.

mpnally commented 8 years ago

It is not clear to me that "the SSO proxy being unable to juggle keys" is a problem. I can make an argument that it is a feature.