-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Cloud Security] Azure integration manual fields #171069
Conversation
Pinging @elastic/kibana-cloud-security-posture (Team:Cloud Security) |
Small UX feedback after looking at the video - The |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code-wise looks good. Tested a bit and had one UX concern that I added as a separate comment. The build is red though
Found couple of issues that need to be fixed
When I've upgraded my installation from 1.6.5 to 1.7.0-preview03, and went to edit my integration. I expected to see the selected credentials type would be See @animehart example of migration: https://github.com/elastic/security-team/issues/7722
The previous reference to the documentation:
basically all the fields except |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
checkout my previous comment
Screen.Recording.2023-11-23.at.15.13.44.mov@kfirpeled thanks for the thorough review, I've added a detailed video with the entire upgrade process that is now working properly. The problem was a bad default value determinator that did not took into account the version of the policy, meaning the value of older integrations would get the default value of the newer ones. managed identity will be the default selected value for new integrations
It doesn't look like we support required fields ATM, we manually set a policy to invalid in some specific cases like trying to save a policy in arm_template or cloud_formation but not having the template url link to the azure/aws pages. but i didnt encounter any infra for invalidating the policy over missing fields. because each field is only required when its option is selected, this change is not straight forward and i'll suggest to create a tech debt task to add support for that. |
I agree but we kinda backed ourself into a corner with the previous integration version using manual as a valid input, in order to keep support in edit we need to provide a matching option in the drop down. the
MB, added a utility function which i later removed, but i left in its tests. cleaned that up as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, lets add a task on our backlog to make the required fields required
@elasticmachine merge upstream |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one nit comment on the latest additions, otherwise looks good!
AZURE_MANUAL_FIELDS_PACKAGE_VERSION | ||
); | ||
|
||
return isPackageVersionValidForManualFields ? 'managed_identity' : 'manual'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I find it a bit confusing that when "package is valid for manual" we return managed identity
otherwise manual
. without the context, I would think it should be the other way around. Maybe change to isPackageVersionValidForManagedIdentity
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
umm this is a very good point, thing is that "manual fields" are meant to reference the entire options (fields) under the Manual credential type, managed identity is just one of them and it happens to be the default value out of those options.
do you think something like isPackageVersionValidForManualOption
is better? i dont mind sticking with your suggestions, just wanted to give more context and see what do you think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I see where the confusion is coming from, that we have Manual as a term that includes multiple setup methods, and inside it we have another Manual
as its own setup method, as in "really manual, you need to do everything yourself" kind of thing. changing to isPackageVersionValidForManualOption
tbh wouldn't change much for me, in the end starting from 1.7.0 we started to support Manual -> Managed Identity
so it became the default, and before it was Manual -> Manual
the default one. So isPackageVersionValidForManagedIdentity
still makes more sense to me (even though it's not only Managed Identity but some other options we started to support) but I'm also ok with a comment in this function to explain this Manual extravaganza, without changing the name :)
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: cc @JordanSh |
Summary
Resolves #165579
Also added all other fields in cooredination with @moukoublen
tenant_id
,client_id
,client_secret
)tenant_id
,client_id
,client_certificate_path
,client_certificate_password
)tenant_id
,client_id
,client_username
,client_password
)Screen.Recording.2023-11-12.at.11.20.13.mov