Cannot delete AWS Mobile Hub project - amazon-web-services

I am a user in a group with an attached policy of AdministratorAccess. Despite this when I attempt to delete an AWS Mobile Hub project, I get the following:
Failed to delete project.
It looks like you do not have permission for this operation.
Then links me to the following page: https://docs.aws.amazon.com/aws-mobile/latest/developerguide/reference-mobile-hub-iam-managed-policies.html

At this time Mobile Hub requires a service role to perform operations in your AWS account, including deleting project resources. You can create the service role at the following link:
https://console.aws.amazon.com/mobilehub/home?#/activaterole/
We are planning on removing the service role in the future so Mobile Hub will use your account permissions to perform actions in your account. Once this change takes effect you will no longer need to have the service role in your account and administrator user permission will work without issue. You can find more information about this change here:
https://docs.aws.amazon.com/aws-mobile/latest/developerguide/reference-mobile-hub-project-permissions-model.html
Sincerely,
Dan G
AWS Mobile Developer Experience

Related

how to restore default service account

similar question: Error on google function deploy, service account doesn't exist but I didnt delete anythin so no ans applies to me
I am following the guide https://cloud.google.com/python/django/flexible-environment
in step https://cloud.google.com/python/django/flexible-environment#store-secret-values-in-secret-manager Configure access to the secret:
however by look into IAM page(with Include Google-provided role grants ),
I discover service account PROJECT_ID#appspot.gserviceaccount.com doesn't exist
how to restore this default account? even if I start a new project, this default account still not there.
I have try to initize a computer engine, the service account is in format projectID-compute#developer.gserviceaccount.com but not in PROJECT_ID#appspot.gserviceaccount.com
turns out that the projects need to have some app engine created in order for that service account to be created

GCP Pub/Sub default service account is not getting created when enabling the API

We have two projects in our GCP account; one for our Dev environment and one for our Test environment at the moment. Terraform manages most of our infrastructure, so we have minimal clicking around the GUI, or CLI commands.
I have assumed we enabled the Pub/Sub API by deploying to it with Terraform in both of our environments, although we may have needed to do this manually. We noticed that Google created a default Pub/Sub service account for us in our Dev environment, but not in our Test environment. This docs page suggests it should make this service account.
Additionally, we have noticed multiple Pub/Sub subscriptions working, apparently without any service account. We believe that the service account is only needed for this particular Subscription because it is a push to an e-mail server. Therefore, it needs a service account with the 'Service Account Token Creator' role.
We've attempted to redeploy the whole infrastructure and disable/re-enable the Pub/Sub API. Neither seemed to kick GCP into creating the Service Account. Further to this, we attempted to make the default service account manually. Still, GCP constrains the name a user can give a service account themselves, so we're unable to create a service account with the name that the Pub/Sub service would expect.
We wonder if there is some configuration of the project we may have missed or if anyone has seen this previously?
Does it not exist or does you not see it?
I'm pretty sure that it exists but without any role granted on it and you don't see it in the UI. Try to grant a role on this default service account, and it will appear in the IAM page!

Can't create job on GCP Cloud Scheduler

When I try to create a job in the GCP Cloud Scheduler I get this error:
{"error":{"code":7,"message":"The principal (user or service account) lacks IAM permission \"iam.serviceAccounts.actAs\" for the resource \"[my service account]\" (or the resource may not exist)."}}
When I enabled the GCP Cloud Scheduler the service account was created (and I can see it in my accounts list). I have verified that it has the "Cloud Scheduler Service Agent" role.
I am logged in as an Owner of our project. It is when I try to create the job that I get this error. I tried to add the "Service Account User" to my principal account, but to no avail.
Does anyone know if I have to add any additional permissions? Or if I have to allow my principal to act (impersonate?) this service account in some way?
Many thanks.
Ben
Ok I figured this out. The documentation is (sort of, in my view) clear if you read it in a certain way / know how GCP IAM works.
You actually need two service accounts. You need one that you set up yourself (can be whatever name you like and doesn't require any special permissions) and you also need the one for Cloud Scheduler itself.
Don't confuse the two. And use the one that you created when specifying the service account to generate the OAuth / OICD tokens.

How do I configure multiple AWS Connect instances from different accounts with AWS Single Sign On in a top level account?

I am setting up our telephony system in AWS and we're utilizing AWS Single Sign On for our primary SAML authentication. This has worked fine for normal cli and console access but has kind of been a struggle for implementing Amazon Connect through the SSO Cloud Applications configuration.
Background
I have done a proof of concept with a single Amazon Connect instance and was able to federate login with a number of different permissions sets to simulate admin, developer, and user access for the single instance. This worked fine until I started adding additional instances and each time any user permission set tries to login to Amazon Connect they get Session Expired on the Connect screen.
Our setup is as follows:
Root account contains AWS SSO Directory
Dev Account has 1 Connect instance in the east
QA Account has 2 Connect instances total in east and west
Prod account has 2 Connect instances total in east and west
A lot of the documentation I've been reading seems it assumes the Amazon Connect instances are in the same account as the Amazon SSO service. Additionally the documentation mentions creating additional IAM Identity Providers for each Amazon Connect instance's SAML Metadata file, and a role associated that allows the SSO user to access that instance. I see where this would work in a single account, but I don't understand how to adopt the access role and implement it as a permissions policy in AWS SSO for the user group thats logging into the instance.
I've configured everything as close as possible to the Amazon Connect SAML Setup Guide, and I'm working on troubleshooting the permissions policy stuff to configure access, I'm just at a loss.
If anyone has previous Amazon SSO experience, or has done something similar with Amazon Connect that would be greatly appreciated. I just want to be able to validate whether this is feasible in the current iteration of Amazon SSO (granted its a newer service), or we need to architect and integrate a 3rd party SSO for Amazon Connect.
Thanks!
We recently have this kind of setup and requirements and still in the testing phase but so far, it is working as expected.
In the Amazon Connect SAML Guide that you linked, there's a lacking piece of information in there with regards to the Attributes Mapping (Step 10)
Change From:
Field: https://aws.amazon.com/SAML/Attributes/Role
Value:
arn:aws:iam::<12-digit-account_id>:saml-provider/,arn:aws:iam::<12-digit-account_id>:role/
To This:
Field: https://aws.amazon.com/SAML/Attributes/Role
Value:
arn:aws:iam::ACCOUNT-ID:saml-provider/IDP_PROVIDER_NAME,arn:aws:iam::ACCOUNT-ID:role/ROLE_NAME
Sample Value:
arn:aws:iam::123456301789:saml-provider/AWSSSO_DevelopmentConnect,arn:aws:iam::123456301789:role/AmazonConnect_Development_Role
The Setup:
Root AWS
Configured with AWS SSO
In AWS SSO page, you can have 1 or more Amazon Connect Applications here
AmazonConnect-Development
AmazonConnect-QAEast
AmazonConnect-QAWest
Dev AWS:
You have setup Amazon Connect
AmazonConnect-Development as the Instance Name (Record the ARN)
Create a new Identity Provider (for ex: AWSSSO_DevelopmentConnect)
Create a Policy (to be attached in the Role)
Create a Role (for ex: AmazonConnect_Development_Role)
See more here for the content of Policy
In Root AWS, configure your AmazonConnect-Development application to have the Attribute Mapping pattern same with my above example value.
You also specify the Relay State URL for you want the users to be redirected to a specific Amazon Connecct application.
xxx AWS:
Same steps will be applied as the above
Key Points:
For each AWS Account:
You will need to Create Identity Provider, name it with a pattern
Create a Policy to be attached in the Role
Create a Role and Choose SAML 2.0 Federation
Checked: Allow programmatic and AWS Management Console access
Link the Identity Provider with the Role
For the Applications that you configure in the AWS SSO page, make sure the additional Attribute Mappings have the correct value

AWS Permissions no longer work after consolidated billing

So we have this aws account with some permissions and it was working fine at first. We were able to deploy to aws using serverless framework. But then the client decided to setup an organization since they have other aws accounts also and to consolidate the billing under 1 account, they added the account they gave us to the organization. Now the problem is when we deployed using serverless again, serverless can no longer see the deployment bucket with an access denied error. But when the account was removed from the organization, serverless is able to locate the bucket. Is there some addition permissions or changes to the permissions that needs to be done when an account is linked to an organization? Can someone explain to me cause I can't seem to find any example of my scenario in a google search. I am new to AWS and this is the first time I experience organzations in AWS.
The only implication to permissions from joining an OU (organization unit) would be via the Service Contol Policy (SCP). Verify that the SCP attached to the organization does not block the actions you are attempting to execute.
We would love to get more information if possible, but I would maybe start looking in the following places in your consolidated account:
Trusted access for AWS services - https://console.aws.amazon.com/organizations/home?#/organization/settings
https://console.aws.amazon.com/organizations/home?#/policies
See if anything was changed there, if someone added a policy, or if the AWS Resource Access Manager is disabled.