- Más nuevo
- Más votos
- Más comentarios
Hi! This is actually documented [1] expected behavior.
**Important **Currently, if your environment’s EC2 instance is launched into a private subnet, you can't use AWS managed temporary credentials to allow the EC2 environment to access an AWS service on behalf of an AWS entity (an IAM user, for example).
As Cloud9 uses EC2 under the hood you can disable temporary credentials and instead attach an instance profile / role [2]. This will allow you to perform the required actions.
[1] https://docs.aws.amazon.com/cloud9/latest/user-guide/security-iam.html
[2] https://docs.aws.amazon.com/cloud9/latest/user-guide/credentials.html#credentials-temporary
What region are you in? Could it be related to this: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html
Good point, I'm in
eu-west-1
, so no issue with the activation.
Contenido relevante
- OFICIAL DE AWSActualizada hace 3 años
- OFICIAL DE AWSActualizada hace un año
Are we sure that the documentation is up-to-date? Because when I navigate to see the deployed CFN template, here is the part of it:
So it attaches an instance profile.
Then how can I run
aws s3 ...
APIs successfully? In this case, shouldn't I expect all AWS APIs not to work in a private subnet?This applies to certain calls such as STS, you are correct that the instance has a role already attached when you launch with the "Private subnet with SSM access (not direct access or SSH access)" option. However unless you disable temporary credentials in the IDE Cloud9 will still try to use them and not the role.
Click on the 9 in the top left > Preferences > AWS Settings > Disable "AWS managed temporary credentials"
That will force Cloud9 to use the role and the aws sts get-caller-identity will now work, however the default role won't have access to other AWS resources defined, so aws s3 ls for example will not work. You will either need to define your own role or attach an appropriate policy.