Ambassador: Ambassador 0.5.0-RC4 attempts to list all secrets in cluster even with AMBASSADOR_SINGLE_NAMESPACE

[davidharkis]

Describe the bug
Ambassador 0.5.0-RC4 attempts to list all secrets in cluster even with AMBASSADOR_SINGLE_NAMESPACE set to true.

To Reproduce
Steps to reproduce the behavior:

1. Run Ambassador with below conditions
   AMBASSADOR_SINGLE_NAMESPACE 'true' & AMBASSADOR_NAMESPACE set
   Service Account that only has access to secrets within the chosen namespace/project
2. Observe log
   ambassador-test-31-5fm8q.log

Expected behavior
Ambassador will only attempt to list secrets within the chosen namespace/project

Versions:

• Ambassador: 0.5.0-RC4
• Kubernetes environment : Openshift
• Version: 3.6

Additional context
Does not occur in RC3

[cornelius-keller]

We can confirm that 0.5.0-RC4 tries to read secrets at cluster scope even if it is configured to be restricted to a single namespace.

[jsrolon]

Just to report, this issue seems to still be present in 0.50.0-rc5.

[richarddli]

Correct, this is mentioned in the release notes: https://blog.getambassador.io/ambassador-0-50-rc5-available-9901d01c7a46

[jmays4]

To add to this issue, it is not only secrets that do not honor single namespace, but the AuthService and route tables are also crossing namespaces when AMBASSADOR_SINGLE_NAMESPACE is set

[christianhuening]

Yeah just ran into this as well! Have 2 namespaces which feature the same naming scheme but different ambassador instances. got a flappy service routing by ambassador in the 2nd namespace as it was shadowed by the instance in the first one.

[kflynn]

Fixed in RC6.

[cornelius-keller]

2019-01-30 07:42:33 diagd 0.50.0 [P45TMainThread] INFO: thread count 33, listening on 0.0.0.0:8877

[2019-01-30 07:42:33 +0000] [45] [INFO] Starting gunicorn 19.9.0

[2019-01-30 07:42:33 +0000] [45] [INFO] Listening at: http://0.0.0.0:8877 (45)

[2019-01-30 07:42:33 +0000] [45] [INFO] Using worker: threads

[2019-01-30 07:42:33 +0000] [78] [INFO] Booting worker with pid: 78

2019-01-30 07:42:33 diagd 0.50.0 [P78TAmbassadorEventWatcher] INFO: starting event watcher

2019-01-30 07:42:33 diagd 0.50.0 [P78TMainThread] INFO: Starting periodic updates

AMBASSADOR: pinging diagd (9)...

AMBASSADOR: diagd running

+ set +x

AMBASSADOR: waiting

PIDS: 43:ambex 44:envoy 45:diagd 85:kubewatch

+ /ambassador/kubewatch --namespace mip-integration --sync 'python3 /ambassador/post_update.py' --warmup-delay 10s secrets services

2019/01/30 07:42:34 secrets is forbidden: User "system:serviceaccount:mip-integration:default" cannot list resource "secrets" in API group "" at the cluster scope

AMBASSADOR: kubewatch exited with status 1

AMBASSADOR: shutting down (1)

Looks much better now. But we still see this in rc7

[davidharkis]

I'm still seeing this in RC6 too.

ambassador-test-39-t524h.log

[kflynn]

Reopening with our apologies – I carefully tested to make sure Ambassador didn't see things outside the namespace, but I just realized that I left RBAC too permissive to catch this. Mea culpa!

[kflynn]

Fixed in #1170.