Add CSM Agentless Read Endpoint #2165
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| 2024-12-18T15:40:11.636Z |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| # Get AWS Scan Options returns "OK" response | ||
|
|
||
| require "datadog_api_client" | ||
| api_instance = DatadogAPIClient::V2::AgentlessScanningAPI.new | ||
| p api_instance.list_aws_scan_options() | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| @endpoint(agentless-scanning) @endpoint(agentless-scanning-v2) | ||
| Feature: Agentless Scanning | ||
| Datadog Agentless Scanning provides visibility into risks and | ||
| vulnerabilities within your hosts, running containers, and serverless | ||
| functions—all without requiring teams to install Agents on every host or | ||
| where Agents cannot be installed. Go to | ||
| https://www.datadoghq.com/blog/agentless-scanning/ to learn more | ||
|
|
||
| @team:DataDog/k9-cloud-security-platform | ||
| Scenario: Get AWS Scan Options returns "OK" response | ||
| Given a valid "apiKeyAuth" key in the system | ||
| And a valid "appKeyAuth" key in the system | ||
| And an instance of "AgentlessScanning" API | ||
| And new "ListAwsScanOptions" request | ||
| When the request is sent | ||
| Then the response status is 200 OK |
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,86 @@ | ||||||
| =begin | ||||||
| #Datadog API V2 Collection | ||||||
|
|
||||||
| #Collection of all Datadog Public endpoints. | ||||||
|
|
||||||
| The version of the OpenAPI document: 1.0 | ||||||
| Contact: [email protected] | ||||||
| Generated by: https://github.com/DataDog/datadog-api-client-ruby/tree/master/.generator | ||||||
|
|
||||||
| Unless explicitly stated otherwise all files in this repository are licensed under the Apache-2.0 License. | ||||||
| This product includes software developed at Datadog (https://www.datadoghq.com/). | ||||||
| Copyright 2020-Present Datadog, Inc. | ||||||
|
|
||||||
| =end | ||||||
|
|
||||||
| require 'cgi' | ||||||
|
|
||||||
| module DatadogAPIClient::V2 | ||||||
| class AgentlessScanningAPI | ||||||
| attr_accessor :api_client | ||||||
|
|
||||||
| def initialize(api_client = DatadogAPIClient::APIClient.default) | ||||||
| @api_client = api_client | ||||||
| end | ||||||
|
|
||||||
| # Get AWS Scan Options. | ||||||
| # | ||||||
| # @see #list_aws_scan_options_with_http_info | ||||||
| def list_aws_scan_options(opts = {}) | ||||||
|
There was a problem hiding this comment. ⚪ Code Quality ViolationAvoid using a hash as an optional parameter (...read more)The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect. This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand. To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using
|
||||||
| data, _status_code, _headers = list_aws_scan_options_with_http_info(opts) | ||||||
| data | ||||||
| end | ||||||
|
|
||||||
| # Get AWS Scan Options. | ||||||
| # | ||||||
| # Fetches the scan options configured for AWS accounts. | ||||||
| # | ||||||
| # @param opts [Hash] the optional parameters | ||||||
| # @return [Array<(AwsScanOptionsResponse, Integer, Hash)>] AwsScanOptionsResponse data, response status code and response headers | ||||||
| def list_aws_scan_options_with_http_info(opts = {}) | ||||||
|
There was a problem hiding this comment. ⚪ Code Quality ViolationAvoid using a hash as an optional parameter (...read more)The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect. This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand. To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using
|
||||||
|
|
||||||
| if @api_client.config.debugging | ||||||
| @api_client.config.logger.debug 'Calling API: AgentlessScanningAPI.list_aws_scan_options ...' | ||||||
| end | ||||||
| # resource path | ||||||
| local_var_path = '/api/v2/agentless_scanning/accounts/aws' | ||||||
|
|
||||||
| # query parameters | ||||||
| query_params = opts[:query_params] || {} | ||||||
|
|
||||||
| # header parameters | ||||||
| header_params = opts[:header_params] || {} | ||||||
| # HTTP header 'Accept' (if needed) | ||||||
| header_params['Accept'] = @api_client.select_header_accept(['application/json']) | ||||||
|
There was a problem hiding this comment. ⚪ Code Quality Violation
Suggested change
Consider using the %w syntax instead (...read more)The rule "Prefer This rule is important because it helps to keep the code concise and easy to read. The To follow this rule, replace the traditional array syntax with the
|
||||||
|
|
||||||
| # form parameters | ||||||
| form_params = opts[:form_params] || {} | ||||||
|
|
||||||
| # http body (model) | ||||||
| post_body = opts[:debug_body] | ||||||
|
|
||||||
| # return_type | ||||||
| return_type = opts[:debug_return_type] || 'AwsScanOptionsResponse' | ||||||
|
|
||||||
| # auth_names | ||||||
| auth_names = opts[:debug_auth_names] || [:apiKeyAuth, :appKeyAuth] | ||||||
|
There was a problem hiding this comment. ⚪ Code Quality Violation
Suggested change
Consider using the %i syntax instead (...read more)The rule "Prefer Symbols are immutable, reusable objects often used in Ruby instead of strings when the value does not need to be changed. When declaring an array of symbols, using the To adhere to this rule, instead of declaring an array of symbols using the literal array syntax like
|
||||||
|
|
||||||
| new_options = opts.merge( | ||||||
| :operation => :list_aws_scan_options, | ||||||
| :header_params => header_params, | ||||||
| :query_params => query_params, | ||||||
| :form_params => form_params, | ||||||
| :body => post_body, | ||||||
| :auth_names => auth_names, | ||||||
| :return_type => return_type, | ||||||
| :api_version => "V2" | ||||||
| ) | ||||||
|
|
||||||
| data, status_code, headers = @api_client.call_api(Net::HTTP::Get, local_var_path, new_options) | ||||||
| if @api_client.config.debugging | ||||||
| @api_client.config.logger.debug "API called: AgentlessScanningAPI#list_aws_scan_options\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}" | ||||||
| end | ||||||
| return data, status_code, headers | ||||||
| end | ||||||
| end | ||||||
| end | ||||||
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 Quality Violation
Do not use parentheses with methods that take no arguments (...read more)
The rule "Avoid parentheses when methods take no arguments" is part of the Ruby style guide. It suggests that when a method takes no arguments, you should not use parentheses. This is because the use of parentheses in such a case is redundant and unnecessary, and it can make your code more difficult to read and understand.
This rule is important because it promotes cleaner, more readable code. In Ruby, clean and readable code is highly valued. By following this rule, you can ensure your code is easier to understand and maintain, which is crucial for long-term project success.
To adhere to this rule, remove the parentheses when calling a method that does not require any arguments. For example, instead of writing
'test'.upcase(), you should write'test'.upcase. Similarly, instead ofKernel.exit!(), writeKernel.exit!. However, note that there is an exception forsuper-superby itself is different fromsuper(), so in this case, parentheses may be necessary.