Configure SAs to enforce mountable secrets #3064
Conversation
|
🤖 Created branch: z_pr3064/skitt/enforce-mountable-secrets |
skitt
force-pushed
the
enforce-mountable-secrets
branch
5 times, most recently
from
0b4ed3e to
cfdfb99
Compare
skitt
requested review from
Oats87,
sridhargaddam,
tpantelis and
vthapar
as code owners
|
Verified by submariner-io/subctl#1128 |
| kubernetes.io/enforce-mountable-secrets: "true" | ||
| secrets: | ||
| - name: submariner-broker-secret | ||
| - name: submariner-ipsec-psk |
There was a problem hiding this comment.
I see you're listing mounted secrets here but not for the others. How come?
There was a problem hiding this comment.
I think this is the only SA that mounts secrets other than the Kubernetes-provisioned secret (which is allowed by default).
There was a problem hiding this comment.
Ah, no, the Lighthouse agent does this too...
There was a problem hiding this comment.
So if specific secrets are not specified, then this will only allow the default K8s-provisioned secret to be mounted?
I wonder how it works with automountServiceAccountToken: false ...
There was a problem hiding this comment.
I think that’s orthogonal: this setting determines which secrets are allowed to be mounted, the automount setting determines whether the default provisioned secret is mounted automatically.
skitt
force-pushed
the
enforce-mountable-secrets
branch
from
cfdfb99 to
8ad86d4
Compare
This prevents accessing arbitrary secrets in pods running with these SAs. See https://kubernetes.io/docs/reference/labels-annotations-taints/#enforce-mountable-secrets for details. Signed-off-by: Stephen Kitt <[email protected]>
skitt
force-pushed
the
enforce-mountable-secrets
branch
from
8ad86d4 to
4735cb9
Compare
|
Should this be backported? |
I think it should, but only after thorough testing — in particular, it reverts submariner-io/subctl#884 so I want to make sure that’s not a problem. |
|
🤖 Closed branches: [z_pr3064/skitt/enforce-mountable-secrets] |
skitt
added
the
backport
What's the plan for getting this testing for devel? Do we want to bump subctl and other repos to this operator version to consume the change? |
That’s already planned, submariner-io/subctl#1128 |
|
We were hoping to see this work in 0.18, including d/s, before backporting it. |
…3064-origin-release-0.17
…3064-origin-release-0.16
This prevents accessing arbitrary secrets in pods running with these SAs. See
https://kubernetes.io/docs/reference/labels-annotations-taints/#enforce-mountable-secrets for details.