A vulnerability was identified in Consul and Consul Enterprise (“Consul”) such that operators with `operator:read` ACL permissions are able to read the Consul Connect CA configuration when explicitly configured with the `/v1/connect/ca/configuration` endpoint, including the private key. This allows the user to effectively privilege escalate by enabling the ability to mint certificates for any Consul Connect services. This would potentially allow them to masquerade (receive/send traffic) as any service in the mesh.
--
This PR increases the permissions required to read the Connect CA's private key when it was configured via the `/connect/ca/configuration` endpoint. They are now `operator:write`.
A vulnerability was identified in Consul and Consul Enterprise (“Consul”) such that operators with `operator:read` ACL permissions are able to read the Consul Connect CA configuration when explicitly configured with the `/v1/connect/ca/configuration` endpoint, including the private key. This allows the user to effectively privilege escalate by enabling the ability to mint certificates for any Consul Connect services. This would potentially allow them to masquerade (receive/send traffic) as any service in the mesh.
--
This PR increases the permissions required to read the Connect CA's private key when it was configured via the `/connect/ca/configuration` endpoint. They are now `operator:write`.
Header is: X-Consul-Default-ACL-Policy=<allow|deny>
This is of particular utility when fetching matching intentions, as the
fallthrough for a request that doesn't match any intentions is to
enforce using the default acl policy.
Consul's Connect CA documentation mentions future releases will
support a pluggable CA system. This sentence has existed in the docs
for over two years, however there are currently no plans to develop
this feature on the near-term roadmap.
This commit removes this sentence to avoid giving the impression that
this feature will be available in an upcoming release.
* Update to CRD docs
* Update website/pages/docs/k8s/crds.mdx
* Modify proxy default and service default protocols
Carry over from previous PR that I forgot to submit a review/suggestion to, TCP and HTTP are not valid protocols for Proxy Defaults and Service Defaults
kubectl apply -f sdefault.yml
Error from server: error when creating "sdefault.yml": admission webhook "mutate-servicedefaults.consul.hashicorp.com" denied the request: servicedefaults.consul.hashicorp.com "your-service-name" is invalid: spec.expose.paths[0].protocol: Invalid value: "tcp": must be one of "http", "http2"
kubectl apply -f sdefault.yml
Error from server: error when creating "sdefault.yml": admission webhook "mutate-servicedefaults.consul.hashicorp.com" denied the request: servicedefaults.consul.hashicorp.com "your-service-name" is invalid: spec.expose.paths[0].protocol: Invalid value: "tcp": must be one of "http", "http2"
Co-authored-by: David Yu <dyu@hashicorp.com>
Rob Taylor
Hans Hasselberg
David Yu
Mike Morris
Kit Patella
Daniel Nephin
Freddy
Sabeen Syed
R.B. Boyer
Matt Keeler
Luke Kysow
Kyle Schochenmaier
Nitya Dhanushkodi
Paul Banks
Joel Watson
Kim Ngo
Kevin Pruett
Kevin Pruett
James Light
Blake Covarrubias