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.
Related
In the AWS website https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html, it shows how to modify the instance user data of an existing EC2.
However, at the end it says the modified user data will not be executed (7). What's the point to modify the user data and not executed? Is it possible to execute the modified user data once?
To modify instance user data
Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
In the navigation pane, choose Instances.
Select the instance and choose Instance state, Stop instance. If this
option is disabled, either the instance is already stopped or its root
device is an instance store volume.
When prompted for confirmation, choose Stop. It can take a few minutes
for the instance to stop.
With the instance still selected, choose Actions, Instance settings,
Edit user data.
Modify the user data as needed, and then choose Save.
Restart the instance. The new user data is visible on your instance
after you restart it; however, user data scripts are not executed.
The User Data field was created as a way to pass information to an instance. For example, providing a password to a database, or configuration information.
Then, the Ubuntu community came up with the clever idea of passing a script via the User Data field, and having some code on the instance execute the script when the system boots. This has enabled "self-configuring" systems, and is called cloud-init.
By default, the User Data script only executes once per instance, with the intention of installing software.
From Boot Stages — cloud-init documentation:
cloud-init ships a command for manually cleaning the cache: cloud-init clean
Running this command will 'forget' the previous runs, and will execute the User Data script on the next boot.
It is also possible to run a script on every boot by placing the script in /var/lib/cloud/scripts/per-boot/.
Simple step to step working Solution:
Stop the Instance
Go to Action > Instance Setting > Edit User Data
And make sure to choose As Text in Edit User Data Screen
Add commands on Textarea
Now start the Instance And check that it is on Running State
check your public IP (This has been changed after restart)
Now finally connect to the instance using ssh :
ssh -i #<IP_ADDRESS>
I'm attempting to use the LDAPAuthenticator class found here to configure JupyterHub on EMR.
I'm querying ActiveDirectory through LDAP to get the authorized users, which are members of a specific AD group.
Problem I'm running into is that with this specific implementation, it expects the user objects to have a few specific user attributes that the objects don't have as of now and I'm not allowed to change them.
The ideal workflow would be, LDAPSEARCH queries ActiveDirectory for a specific AD group, and on return it creates users for the members of that AD group, it should create linux users and directories for the users.
I'd like to know if anyone else has run into this sort of issue and overcome, thanks!
If you get stuck in the same place, I ended up using this:
https://github.com/hansohn/jupyterhub-ldap-authenticator
and it work as expected.
I created an instance with Debian 9 and was following the instructions on Google's site here. I have done this before successfully. All was going fine, but now when I do this part:
DISPLAY= /opt/google/chrome-remote-desktop/start-host \
--code="4/xxxxxxxxxxxxxxxxxxxxxxxx" \
--redirect-url="https://remotedesktop.google.com/_/oauthredirect" \
--name=
I get the error
Adding user newuser_gmail_com to group chrome-remote-desktop
ERROR:Failed to access chrome-remote-desktop group. Is the user a
member?
Can anyone help me out here? I notice that when I did this previously, the username create was not newuser_gmail_com, but rather simply newuser. Any suggestions you have would be much appreciated. Many thanks!
I found the answer, but this raises a possible bug for the Google Cloud team. The bug occurs if I add enable-oslogin = TRUE as a metadata. This causes the chrome-remote-desktop to fail.
When a user is added to a group (chrome-remote-desktop in this case), the change is not reflected in existing sessions until the user logs out and back in. To work around this limitation, Chrome Remote Desktop attempts to use sg to access the new group from the existing session. It looks like this isn't working for some reason on this system (apparently OS Login related?), so starting the host fails.
It should be sufficient to log out and back in. Once logged back in, very that the output of groups contains chrome-remote-desktop, then try running the headless setup flow again. (Make sure you generate a new command, as the --code argument is one-time-use only.)
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 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)