Add secret_paths attributes to policies sent to agents #3908
Conversation
Add a new attribute "secret_paths" to the policy data sent to agents. This attribute is a list of keys where the fleet-server has repalced a reference with a secret value. The agent is expected to redact the values of these keys when outputting policy data.
michel-laterman
added
enhancement
|
This pull request does not have a backport label. Could you fix it @michel-laterman? 🙏
|
|
|
mergify
bot
added
the
backport-8.x
michel-laterman
force-pushed
the
policy-change-list-secert-keys
branch
from
b411fea
to
d656c3f
Compare
michel-laterman
force-pushed
the
policy-change-list-secert-keys
branch
from
d656c3f
to
ba13964
Compare
| @@ -522,6 +522,11 @@ components: | |||
| id: | |||
| description: The policy's ID. | |||
| type: string | |||
| secret_paths: | |||
There was a problem hiding this comment.
Since this is outside of the signed section of the policy, in theory it could be modified to cause agent to not redact secrets locally couldn't it?
To put it in the signed section of the policy, we'd have to determine which fields contain secrets in Kibana instead, because that is where the signing key resides.
Is there a reason why we can't put these in Kibana?
There was a problem hiding this comment.
OK, thinking more deeply, I was thinking through a scenario where someone had intercepted the checkin response, and wanted to to force the agent to disclose secrets by removing the redaction hints.
However, if they have the checkin response after Fleet Server has touched it and added these keys, they already have the replaced secret values that Fleet Server inserted.
So I don't think there is a point in doing this because it doesn't protect us from anything.
|
In addition to my bigger picture question about being able to sign the secret_paths, SonarQube says there are some non-error paths in replaceSliceRefs that have no test coverage. |
internal/pkg/policy/secret.go
Outdated
| case string: | ||
| ref, replaced := replaceStringRef(value, secrets) | ||
| if replaced { | ||
| keys = append(keys, fmt.Sprintf("[%d]", i)) |
There was a problem hiding this comment.
I'm going to delay merging this as I think go-ucfg uses . when accessing array values.
There was a problem hiding this comment.
elastic/elastic-agent#5621
go-ucfg does use . when accessing arrays
|
Add a new attribute "secret_paths" to the policy data sent to agents. This attribute is a list of keys where the fleet-server has repalced a reference with a secret value. The agent is expected to redact the values of these keys when outputting policy data. (cherry picked from commit 4864cf4)
Add a new attribute "secret_paths" to the policy data sent to agents. This attribute is a list of keys where the fleet-server has repalced a reference with a secret value. The agent is expected to redact the values of these keys when outputting policy data. (cherry picked from commit 4864cf4) Co-authored-by: Michel Laterman <82832767+michel-laterman@users.noreply.github.com>
What is the problem this PR solves?
Agent cannot determine where secrets have been injected into a policy.
How does this PR solve the problem?
Add a new attribute
secret_pathsto the policy data sent to agents. This attribute is a list of keys where the fleet-server has repalced a reference with a secret value. The agent is expected to redact the values of these keys when outputting policy data.Design Checklist
I have or intend to scale test my changes, ensuring it will work reliably with 100K+ agents connected.I have included fail safe mechanisms to limit the load on fleet-server: rate limiting, circuit breakers, caching, load shedding, etc.Checklist
I have made corresponding changes to the documentationI have made corresponding change to the default configuration files./changelog/fragmentsusing the changelog tool