[Fleet][Agent Policy][Agent Tamper Protection] UI / API guard agent tamper protection only available if security defend integration present#162196
Conversation
…g-with-defend-only
…g-with-defend-only
…g-with-defend-only
…g-with-defend-only
…g-with-defend-only
dasansol92
left a comment
There was a problem hiding this comment.
Looking good! Thanks for work on this! Left few suggestions and questions. Let me know your thoughts.
| export function isAgentPolicy( | ||
| policy: Partial<NewAgentPolicy | AgentPolicy> | ||
| ): policy is AgentPolicy { | ||
| return (policy as AgentPolicy).is_protected !== undefined; |
There was a problem hiding this comment.
Can we use other more specific prop in Agent policy to check if it is an agent policy or not?
There was a problem hiding this comment.
do you think revision in AgentPolicy works better maybe?
| namespace: 'default', | ||
| monitoring_enabled: ['logs', 'metrics'], | ||
| inactivity_timeout: 1209600, | ||
| is_protected: false, |
There was a problem hiding this comment.
why are we removing this?
There was a problem hiding this comment.
We want to take this out since NewPackagePolicy doesn't have package_policies, and therefore the defend integration, during creation, and to prevent users from modifying this field. Even if a user were to add the defend integration to a new agent policy, as opposed to an existing one, the new agent policy is created first before adding the defend package policy, and then at this point, the is_protected field would be available but defaulted to false.
| namespace: 'default', | ||
| monitoring_enabled: Object.values(dataTypes), | ||
| inactivity_timeout: TWO_WEEKS_SECONDS, | ||
| is_protected: false, |
There was a problem hiding this comment.
same as above - removing is_protected from the NewAgentPolicy type
| fleet_server_host_id?: string | null; | ||
| schema_version?: string; | ||
| agent_features?: Array<{ name: string; enabled: boolean }>; | ||
| is_protected?: boolean; |
There was a problem hiding this comment.
This was optional, why are we removing this?
| }); | ||
| expect(mockUpdateAgentPolicy).toHaveBeenCalledWith({ is_protected: true }); | ||
| }); | ||
| describe('when the defend integration is not installed', () => { |
There was a problem hiding this comment.
Do we have test cases for when it has Defend Integration? If not, can we add those?
There was a problem hiding this comment.
yes, the other tests above have the defend integration inside the package policy
| id="xpack.fleet.agentPolicyForm.tamperingSwitchLabel" | ||
| defaultMessage="Prevent agent tampering" | ||
| />{' '} | ||
| {!policyHasEndpointSecurity(agentPolicy) && ( |
There was a problem hiding this comment.
Can we store and memoize the !policyHasEndpointSecurity(agentPolicy) in a const and use it below?
There was a problem hiding this comment.
Same thing for the isAgentPolicy...
| color="subdued" | ||
| content={i18n.translate( | ||
| 'xpack.fleet.agentPolicyForm.tamperingSwitchLabel.disabledWarning', | ||
| { defaultMessage: 'this is why its disabled' } |
There was a problem hiding this comment.
I guess we are waiting for a proper message here, right?
There was a problem hiding this comment.
@roxana-gheorghe Do we know what we want to have for the disabled messaging when the defend integration is not present?
| savedObjectType: AGENT_POLICY_SAVED_OBJECT_TYPE, | ||
| }); | ||
|
|
||
| this.checkTamperProtectionLicense(agentPolicy); |
There was a problem hiding this comment.
Why we remove this here?
There was a problem hiding this comment.
since we are no longer sending in agent tamper protection on agent policy create, there is no need for a license check since agent tamper protection is the only licensed-gated feature
| const agentPoliciesWithEndpointPackagePolicies = [ | ||
| ...new Set( | ||
| result | ||
| .filter((r) => r.success && r.policy_id && r.package?.name === 'endpoint') |
There was a problem hiding this comment.
Could we use a single reduce here instead?
| ...new Set(result.filter((r) => r.success && r.policy_id).map((r) => r.policy_id!)), | ||
| ]; | ||
|
|
||
| const agentPoliciesWithEndpointPackagePolicies = [ |
There was a problem hiding this comment.
This could be a Set, so no array transformation is needed. Then below you can use the .has method from Set instead of array inculdes
…g-with-defend-only
…g-with-defend-only
…g-with-defend-only
…g-with-defend-only
…g-with-defend-only
…g-with-defend-only
…g-with-defend-only
…g-with-defend-only
|
Pinging @elastic/security-defend-workflows (Team:Defend Workflows) |
| description: 'test description', | ||
| namespace: 'test-namespace', | ||
| monitoring_enabled: ['logs'], | ||
| is_protected: true, |
There was a problem hiding this comment.
should we add this again?
There was a problem hiding this comment.
we could add with false
There was a problem hiding this comment.
I suppose we could, but I wonder if it makes sense to have a test that changes this since we don't want to generate a new policy with is_protected being true since elastic defend is not present in a New Agent Policy. But I guess if we are just testing functionality, I could? Or maybe I should enforce the code so that the user can't modify is_protected as an override prop? What do you think @dasansol92
There was a problem hiding this comment.
We could test both scenarios, when user sets it to false (it is ok) and when user sets it to true (and we turn it back to false). Also when the prop is not set, and we set it to false.
There was a problem hiding this comment.
@parkiino you were right, since this is only testing the generateNewAgentPolicyWithDefaults and not the API functionality, it's ok to keep it as it is (is_protected set to false by default when it is not assigned). @juliaElastic let me know if you think different.
| <FormattedMessage | ||
| id="xpack.fleet.agentPolicyForm.tamperingSwitchLabel" | ||
| defaultMessage="Prevent agent tampering" | ||
| />{' '} |
There was a problem hiding this comment.
Is this empty space needed?
There was a problem hiding this comment.
Yes, otherwise the tooltip icon would be right up against the text
| color="subdued" | ||
| content={i18n.translate( | ||
| 'xpack.fleet.agentPolicyForm.tamperingSwitchLabel.disabledWarning', | ||
| { defaultMessage: 'this is why its disabled' } |
There was a problem hiding this comment.
Taking this back @roxana-gheorghe, do we have a proper text for this one?
dasansol92
left a comment
There was a problem hiding this comment.
Pending to update tooltip text. Other than that, it looks good! Thanks for working on this 🔥
💚 Build Succeeded
Metrics [docs]Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
…amper protection only available if security defend integration present (elastic#162196) ## Summary UI - [x] When there is no elastic defend integration present, the agent tamper protection (`is_protected`) switch and instruction link are disabled and there is an info tooltip explaining why the switch is disabled API - [x] Requires the elastic defend integration to be present, in order to set `is_protected` to true. Will allow the user to create the agent policy and not throw an error, but will keep `is_protected` as false and log a warning in the kibana server. In the next release, the response will be modified to send back a 201 with the relevant messaging. - [x] Sets `is_protected` to false when a user deletes the elastic defend package policy ## Screenshots ### No Elastic Defend integration installed <img width="970" alt="image" src="https://github.com/elastic/kibana/assets/56409205/910be766-1a1e-4580-9ace-306089b4626d">
Summary
UI
is_protected) switch and instruction link are disabled and there is an info tooltip explaining why the switch is disabledAPI
is_protectedto true. Will allow the user to create the agent policy and not throw an error, but will keepis_protectedas false and log a warning in the kibana server. In the next release, the response will be modified to send back a 201 with the relevant messaging.is_protectedto false when a user deletes the elastic defend package policyScreenshots
No Elastic Defend integration installed