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`.
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>
* Add NIA Integration Program page
* Update name to Consul-Terraform-Sync and add Tech Preview tags
* Update diagram to include sequence numbers
* Remove Tech Preview tags and Update Images
* Add TF module naming convention, update image and links
* Add a note, update PANW link, and working updates
* Update URLs to local path
This allows for client agent to be run in a more stateless manner where they may be abruptly terminated and not expected to come back. If advertising a per-agent reconnect timeout using the advertise_reconnect_timeout configuration when that agent leaves, other agents will wait only that amount of time for the agent to come back before reaping it.
This has the advantageous side effect of causing servers to deregister the node/services/checks for that agent sooner than if the global reconnect_timeout was used.
* Update the Azure cloud auto join documentation with more explicit information on how to configure the infrastructure.
* Add a note regarding the length of time taken for Azure to sync the MSI permissions.
* Update references from tag_name to tag_key in the Azure examples
Co-authored-by: Jono Sosulska <42216911+jsosulska@users.noreply.github.com>
Daniel Nephin
Freddy
Sabeen Syed
Kit Patella
R.B. Boyer
Mike Morris
Matt Keeler
Luke Kysow
Kyle Schochenmaier
Nitya Dhanushkodi
Paul Banks
Joel Watson
Kim Ngo
Kevin Pruett
Kevin Pruett
James Light
Blake Covarrubias
Preetha
Peter M
Kyle Havlovitz
Lorna Song
Brandon Romano
pcmccarron
Iryna Shustava
Ricardo Oliveira
s-christoff
Ashwin Venkatesh
Jimmy Merritello
Ryan Ooi
Chris Piraino
Michael Hofer
Petrik van der Velde