[community.aws.aws_ssm] Let user define which SSM document to use for start session #613
Labels
feature
This issue/PR relates to a feature request
module
module
needs_triage
plugins
plugin (any type)
Comments
giom-l
changed the title
|
Files identified in the description:
If these files are inaccurate, please update the |
ansibullbot
added
feature
alinabuzachis
pushed a commit
to alinabuzachis/community.aws
that referenced
this issue
May 25, 2022
…e_table_ids (ansible-collections#613) ec2_vpc_endpoint: improve documentation to provide details about route_table_ids SUMMARY Modify documentation to specify that while creating VPC endpoint using ec2_vpc_endpoint, route table IDs are only valid for gateway type endpoints. As specified in the API doc: RouteTableIds (list) -- (Gateway endpoint) One or more route table IDs. Fixes ansible-collections#576 ISSUE TYPE Docs Pull Request COMPONENT NAME ec2_vpc_endpoint ADDITIONAL INFORMATION API Doc: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2.html#EC2.Client.create_vpc_endpoint Reviewed-by: Alina Buzachis <None> Reviewed-by: Jill R <None> Reviewed-by: None <None>
|
Support for setting an SSM document was added by #876 and should be available with release 5.2.0 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
SUMMARY
By default, Session Manager will use the default document to start a session, which is
SSM-SessionManagerRunShell.However, it could be a really nice thing to be able to define which document we want to use.
ISSUE TYPE
COMPONENT NAME
community.aws.aws_ssm
plugins/connection/aws_ssm.py
ADDITIONAL INFORMATION
One can think about logging all what is done during ssm sessions opened on an AWS account.
To do that, I think it is pretty common to define our own SSM document, with specific configuration like specifying S3 bucket to send logs to (or Cloudwatch equivalent).
Obviously, it can be done on default SSM document but that becomes unusable in shared accounts, where each project/team may want to have its own outputs.
I also think that modification of AWS provided stuffs (like policies of SSM documents) is discouraged by AWS itself (as it could break if AWS decides to change it).
Providing the ability to specify which SSM document to use would be a great trick (with verification that this document exist before trying to run it)
The text was updated successfully, but these errors were encountered: