The ACL policy examples documented on the Consul Storage Backend and
Consul Service Registration pages are too permissive. Both policies
unnecessarily grant agent:write and node:write access for all agents
within the Consul datacenter. When Consul is used solely for service
registration, `service:write` is only required permission.
This commit modifies the policy for the Consul Storage Backend to
remove node:write access, and changes agent:write to agent:read.
The policy on the Consul Service Registration page is updated to
remove all KV-related privileges, and solely grant the necessary
service:write permission.
* fix: upgrade vault-plugin-auth-kubernetes
- brings in the alias_name_source feature which allows for setting
alternate alias names based on the service accounts's namespace and
name
- document the seurity related aspects for the feature addition above.
* Docs: Seal pkcs11 updated example with actual hex slot reference and notes related to decimal conversion. Minor correction to **Note** area in 'lib' parameter above 'slot'.
* Docs: Seal pkcs11 slot note correction.
* [VAULT-3519] Return no_default_policy on token role read if set
* [VAULT-3519] Add changelog
* [VAULT-3519] Always return token_no_default_policy on role read
* Fix broken test
* Update role read response in docs
* Add allowed_policies_glob and disallowed_policies_glob that are the same as allowed_policies and disallowed_policies but allow glob matching.
* Update changelog, docs, tests, and comments for (dis)allowed_token_glob token role feature.
* Improve docs and unit tests for auth/token role policy globbing.
* Enforce Minimum cache size for transit backend
* enfore minimum cache size and log a warning during backend construction
* Update documentation for transit backend cache configuration
* Added changelog
* Addressed review feedback and added unit test
* Modify code in pathCacheConfigWrite to make use of the updated cache size
* Updated code to refresh cache size on transit backend without restart
* Update code to acquire read and write locks appropriately
While EKS may be the managed kubernetes environment under the hood, I believe the idea behind this section of the documentation is to use AWS KMS for seal/unseal operations, not EKS. (i.e. The surrounding documentation is discussing other Auto Unseal options such as Google KMS.)
The use of the term EKS instead of KMS made it hard for me to discover this section of documentation, and was a little confusing at first until I realized the possible error.
Meggie