Hey! I have the following case.
I created ServiceAccounts for client “a” in namespace bar, for client “b” in namespace foo.
apiVersion: v1
kind: ServiceAccount
metadata:
name: service-a
Deployed two clients and http-server. Created a ServiceRole to access the http-server.
apiVersion: rbac.istio.io/v1alpha1
kind: ServiceRole
metadata:
name: viewer
namespace: security
spec:
rules:
- services: [“http-server”]
methods: [POST]
thus, client " a “can make post requests to the server, client” b " cannot make requests. But if you compromise the ServiceAccount data of client “a”: copy the key and the certificate chain and paste it into ServiceAccount for client" b", client" b " will be able to make requests to the http server from another namespace. Prompt, please, how not to allow access to the http server if the certificate is compromised
If the private key of the certificate is leaked, it basically means everyone who has it could send a request on behalf of the identity of the certificate. We cannot prevent such cases as it’s something beyond our control (the client has the responsibility to keep its private key really private).
Could you clarify more about what’s the use case for a compromised certificate? Thanks.
After client " b " has replaced in its ServiceAccount the values of cert-chain and key.pem on those that the client “a”, he gained access to the http-server with the same privileges as the client" a " (for example, was able to make post-requests). Q: is there any way to further protect access to the http-server? For example, make a bundle: a client with “such a ServiceAccount and, for example, from a certain namespace”. For other users access is closed. Because it turns out that if the certificate is compromised, there is no additional protection. Such code variants in ServiceRoleBinding also don’t work (client " b " still has access to the server)
subject:
- properties:
source.principal: “cluster.local/ns/bar/sa/service-a”
source.namespace: “bar”