I have shared a bunch of AMIs from an AWS account to another.
I used this EC2conn1.modify_image_attribute(AMI_id, operation='add', attribute='launchPermission', user_ids=[second_aws_account_id]) to do it.
But, by only adding launch permission for the 2nd account, I can launch an instance but I cannot copy the shared AMI to another region [in the 2nd account].
When I tick the checkbox to "create volume" from the UI of the 1st account, I can copy the shared AMI from the 2nd:
I can modify the launch permissions using the modify_image_attribute function from boto.
In the documentation says, attribute (string) – The attribute you wish to change but I understand that it can only change the launch permissions and add an account.
Yet, the get_image_attribute has 3 options Valid choices are: * launchPermission * productCodes * blockDeviceMapping.
So, is there a way to programmatically change it from the API along with the launch permissions or, it has not been implemented yet??
The console uses the API so there's almost nothing you can do in the console that you can't to using the API.
Remember that an AMI is just a configuration entity -- basic launch configuration, linked to (not containing) one or more backing snapshots, which are technically separate entities.
The console is almost certainly making an additional API request the ModifySnapshotAttribute API when it offers to optionally "add Create Volume permissions to the following associated snapshot."
See also http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html
Presumably, copying a snapshot to another region relies on the same "Create Volume" permission (indeed, you'll see that a copied snapshot has a fake source volume ID, presumably an artifact of the copying process).
Based on the accepted answer, this is the code I wrote for anyone interested.
# Add copy permission to the image's snapshot
# Find the snapshot of the specific AMI
image_object = EC2conn.get_image(AMI_id)
# Grab the block device mapping dynamically
ami_devices = []
for key in image_object.block_device_mapping.iterkeys():
# print key #debug
ami_devices.append(key)
# print ami_devices #debug
for ami_device in ami_devices:
snap_id = image_object.block_device_mapping[ami_device].snapshot_id
# Add permission
EC2conn.modify_snapshot_attribute(snap_id, attribute='createVolumePermission', operation='add', user_ids=second_aws_account_id)
print "{0} [{1}] Permission added to snapshot".format(AMI_name,snap_id)
Related
As from the title need to allow an external user to start/stop the instance he will work on and nothing else, it's a topic I found already answers, and did setup for the specific project the a custom role "StartStopCE" with these permissions:
compute.instances.get
compute.instances.list
compute.instances.osLogin
compute.instances.reset
compute.instances.resume
compute.instances.start
compute.instances.stop
compute.instances.suspend
serviceusage.services.list
Testing with one of my secondary Google accounts (not the one I'm Owner in GCP) all is working fine and I'm allowed only to list the VM Instances and start/stop/etc.
The external user was allowed to do so only the first time we was experiementing with the various persmissions, next when he tried to start the instance this disappeared after he started it, and after that he got only this page trying to access the VM Instances list
We have tried to delete and recreate his user, use a second Google user, logout/login, change browser, delete cache.
My test user has the very same assigned role and worked fine, I don't know what elese to check.
I tried to create new AWS key pairs and the option to create disappeared
Does anyone know why?
It would be worth checking the IAM permissions associated with the User who is trying to create the key pair. Contact the Administrator (presumably you?) and investigate. I would suggest creating a Group with Permissions and adding them to that.
I performed an experiment and added aDeny policy to my IAM User that prevented me from being able to create a keypair.
I then tried to launch an instance and the option to create a keypair (in the dialog box you show above) was still available. So, the display does not vary according to permissions.
Therefore, something else is causing your situation. I would recommend trying it in a different browser. Also, check the underlying HTML to see whether the option is coded on the web page. Something is causing it to disappear.
I am attempting to import an existing EC2 instance into Terraform. I have taken the EC2 instance User Data, and added it to my TF config file e.g.
user_data = <<EOF
<powershell>
& $env:SystemRoot\System32\control.exe "intl.cpl,,/f:`"UKRegion.xml`""
& tzutil /s "GMT Standard Time"
Set-Culture en-GB
</powershell>
EOF
The resource imports OK, but when I run terraform plan I get TF wanting to destroy and recreate the instance, as a 'change' in user_data 'forces new resource'.
user_data: "946f756af0df239b19f86a72653e58dcc04c4b27" => "811599030dc713b18c3e35437a82b35095190a81" (forces new resource)
I have tried copy and pasting the user data from EC2 console into the TF file, but this is not working. Is this at all possible?
You can't copy the user_data value from the state, as it is an encoded string and if you copy it into the resource configuration, it'll get encoded again before it is compared to the current state, and it won't match.
But you can copy the current user data value from the Instance settings in the EC2 Console, and paste it into the user_data attribute of the resoure in the .tf file.
If there are multiple lines of data, you will need to replace each new-line with a \n in the file, as you can't use a multi-line string.
For example:
resource "aws_instance" "instance1" {
ami = "ami-0123456789abcdef0"
instance_type = "t4.medium"
user_data = "setting1=value\nsetting2=value\nsetting3=value"
}
Note: there is a 16KB size limit on the user data in EC2, but if you're copying from EC2 to your Terraform configuration, this won't be an issue. (But it will make it difficult to read and manage, so you may want to consider storing the config in a custom image instead.)
Or, as you suggested already, if your setup supports this and you can afford to shut the instance down temporarily, remove the user data from the instance settings altogether.
Per this github issue, it looks like this is an issue with how terraform interprets the user_data as a "computed" value. There appears to be a work around.
First run a plan/apply cycle with your plan command including the extra argument on your command line:
-target=template_file.userdata-consul. This will tell Terraform to do the minimal work it needs to update the template file, which should
leave your launch configuration untouched.
Now run plan again, and since the template_file has now already been recreated it should interpolate the resolved template as
expected into the user_data, and there should then be no diff
because the "new" template rendering should be the same as the
"old" one.
I have a task of implementing a basic backup and recovery system within a django app. I have heard of pyvmomi, but never used it before.
My specific tasks at hand is:
1) make a call to a vCenter, pass the vm name, and request to make a snapshot
2) obtain the file location of the snapshot
3) and upload the snapshot file into an OpenStack Swift object store
What is the actual syntax of creating a vm snapshot using pyvmomi?
Also - what is the syntax to request the actual snapshot file from vCenter?
https://github.com/rreubenur/vmware-pyvmomi-examples/blob/master/create_and_remove_snapshot.py
This should be helpful
Snapshot task result itself contains Moref to snashot created
So that you can get reference to created snapshot.
I am trying to create a role within Sitecore which can publish content, but only within a specific area(s) of the site. I've added the standard Sitecore\Client Publishing role to my role, but I can't see how to prevent the role from being able to publish all areas of the site. I've looked at the Security editor and the Access viewer, but setting the write access of the sections only seems to affect the ability to edit those sections and has no effect on the ability to publish on those sections.
Workflow is the typical way this is handled. Giving roles access to approve (this could be called 'publish') content of certain sections of the content tree will be the best way to achieve what you are describing. Combine this with an auto-publish action to make it more user friendly.
One thing to keep in mind though using this method is referenced items (images from media library the content may be using for example). Take a look at the 'Publishing Spider' module on the shared source library http://trac.sitecore.net/PublishingSpider
EDIT: Update
I recently discovered this setting in the web.config: "Publishing.CheckSecurity". If set to true, this setting will only publish items if the user has read + write on the item and will only remove items from the web DB if the user has delete permissions.
I had a similar situation once and I created roles per section which only had read and write to that section and no where else (let say 'editor section 1') and another role which only had publishing permission for that section (let say 'publisher section 1'). Then added 'editor section 1' role to 'publisher section 1' role which gives you the role for publishing only specific section.
You do not need multiple workflows, same workflow with multiple roles can also achieve this goal
Answer to this is to set Publishing.CheckSecurity to true
You need to find this code inside web
<!-- PUBLISHING SECURITY
Check security rights when publishing?
When CheckSecurity=true, Read rights are required for all source items. When it is
determined that an item should be updated or created in the target database,
Write right is required on the source item. If it is determined that the item
should be deleted from target database, Delete right is required on the target item.
In summary, only the Read, Write and Delete rights are used. All other rights are ignored.
Default value: false
-->
<setting name="Publishing.CheckSecurity" value="false" />
Set the value="true"
But again you have to govern the security tightly, and assign user role properly. Failed to
do so you will experience buggy publishing.
Hope that will help