|
10 | 10 |
|
11 | 11 | SSO Sync will run on any platform that Go can build for. It is available in the [AWS Serverless Application Repository](https://console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-2:004480582608:applications/SSOSync) |
12 | 12 |
|
13 | | -> :warning: there are breaking changes for versions `>= 0.02` |
| 13 | +> [!CAUTION] |
| 14 | +> When using ssosync with an instance or IAM Identity Center integrated with AWS Control Tower. AWS Control Tower creates a number of groups and users (directly via the Identity Store API), when an external identity provider is configured these users and groups are can not be used to log in. However it is important to remember that because ssosync implemements a uni-directional sync it will make the IAM Identity Store match the subset of your Google Workspaces directory you specify, including removing these groups and users created by AWS Control Tower. There is a PFR [#88 - ssosync deletes Control Tower groups](https://github.com/awslabs/ssosync/issues/88) to implement an option to ignore these users and groups, hopefully this will be implemented in version 3.x. |
14 | 15 |
|
15 | | -> :warning: `>= 1.0.0-rc.5` groups to do not get deleted in AWS SSO when deleted in the Google Directory, and groups are synced by their email address |
| 16 | +> [!WARNING] |
| 17 | +> There are breaking changes for versions `>= 0.02` |
16 | 18 |
|
17 | | -> :warning: `>= 2.0.0` this makes use of the **Identity Store API** which means: |
18 | | -* if deploying the lambda from the [AWS Serverless Application Repository](https://console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-2:004480582608:applications/SSOSync) then it needs to be deployed into the [IAM Identity Center delegated administration](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html) account. Technically you could deploy in the management account but we would recommend against this. |
19 | | -* if you are running the project as a cli tool, then the environment will need to be using credentials of a user in the [IAM Identity Center delegated administration](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html) account, with appropriate permissions. |
| 19 | +> [!WARNING] |
| 20 | +> `>= 1.0.0-rc.5` groups to do not get deleted in AWS SSO when deleted in the Google Directory, and groups are synced by their email address |
| 21 | +
|
| 22 | +> [!WARNING] |
| 23 | +> `>= 2.0.0` this makes use of the **Identity Store API** which means: |
| 24 | +> * if deploying the lambda from the [AWS Serverless Application Repository](https://console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-2:004480582608:applications/SSOSync) then it needs to be deployed into the [IAM Identity Center delegated administration](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html) account. Technically you could deploy in the management account but we would recommend against this. |
| 25 | +> * if you are running the project as a cli tool, then the environment will need to be using credentials of a user in the [IAM Identity Center delegated administration](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html) account, with appropriate permissions. |
| 26 | +
|
| 27 | +> [!WARNING] |
| 28 | +> `>= 2.1.0` make use of named IAM resources, so if deploying via CICD or IaC template will require **CAPABILITY_NAMED_IAM** to be specified. |
| 29 | +
|
| 30 | +> [!IMPORTANT] |
| 31 | +> `>= 2.1.0` switched to using `provided.al2` powered by ARM64 instances. |
20 | 32 |
|
21 | 33 | ## Why? |
22 | 34 |
|
@@ -161,22 +173,49 @@ Flags Notes: |
161 | 173 | * `--group-match` works for both `--sync-method` values and also in combination with `--ignore-groups` and `--ignore-users`. This is the filter query passed to the [Google Workspace Directory API when search Groups](https://developers.google.com/admin-sdk/directory/v1/guides/search-groups), if the flag is not used, groups are not filtered. |
162 | 174 | * `--user-match` works for both `--sync-method` values and also in combination with `--ignore-groups` and `--ignore-users`. This is the filter query passed to the [Google Workspace Directory API when search Users](https://developers.google.com/admin-sdk/directory/v1/guides/search-users), if the flag is not used, users are not filtered. |
163 | 175 |
|
164 | | -NOTES: |
165 | | - |
166 | | -1. Depending on the number of users and groups you have, maybe you can get `AWS SSO SCIM API rate limits errors`, and more frequently happens if you execute the sync many times in a short time. |
167 | | -2. Depending on the number of users and groups you have, `--debug` flag generate too much logs lines in your AWS Lambda function. So test it in locally with the `--debug` flag enabled and disable it when you use a AWS Lambda function. |
| 176 | +> [!NOTE] |
| 177 | +> 1. Depending on the number of users and groups you have, maybe you can get `AWS SSO SCIM API rate limits errors`, and more frequently happens if you execute the sync many times in a short time. |
| 178 | +> 2. Depending on the number of users and groups you have, `--debug` flag generate too much logs lines in your AWS Lambda function. So test it in locally with the `--debug` flag enabled and disable it when you use a AWS Lambda function. |
168 | 179 |
|
169 | 180 | ## AWS Lambda Usage |
170 | 181 |
|
171 | | -NOTE: Using Lambda may incur costs in your AWS account. Please make sure you have checked |
| 182 | +> [!TIP] |
| 183 | +> Using Lambda may incur costs in your AWS account. Please make sure you have checked |
172 | 184 | the pricing for AWS Lambda and CloudWatch before continuing. |
173 | 185 |
|
174 | 186 | Additionally, before choosing to deploy with Lambda, please ensure that the [AWS Lambda SLAs](https://aws.amazon.com/lambda/sla/) are sufficient for your use cases. |
175 | 187 |
|
176 | 188 | Running ssosync once means that any changes to your Google directory will not appear in |
177 | 189 | AWS SSO. To sync regularly, you can run ssosync via AWS Lambda. |
178 | 190 |
|
179 | | -:warning: You find it in the [AWS Serverless Application Repository](https://eu-west-1.console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-2:004480582608:applications/SSOSync). |
| 191 | +> [!WARNING] |
| 192 | +> You find it in the [AWS Serverless Application Repository](https://eu-west-1.console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-2:004480582608:applications/SSOSync). |
| 193 | +
|
| 194 | +> [!TIP] |
| 195 | +> ### v2.1 Changes |
| 196 | +> * user and group selection fields in the Cloudformation template can now be left empty where not required and will not be added as environment variables to the Lambda function, this provides consistency with CLI use of ssosync. |
| 197 | +> * Stronger validation of parameters in the Cloudformation template, to improve likelhood of success for new users. |
| 198 | +> * Now supports multiple deployment patterns, defaults are consistent with previous versions. |
| 199 | +
|
| 200 | +**App + secrets** This is the default mode and fully backwards compatible with previous versions |
| 201 | + |
| 202 | +**App only** This mode does not create the secrets but expects you to deployed a separate stack using the **Secrets only** mode within the same account |
| 203 | +> [!CAUTION] |
| 204 | +> If you want to use your own existing secrets then provide them as a comma separated list in the ##CrossStackConfigI## field in the following order: |
| 205 | +> __GoogleCredentials ARN__,__GoogleAdminEmail ARN__,__SCIMEndpoint ARN__,__SCIMAccessToken ARN__,__Region ARN__,__IdentityStoreID ARN__ |
| 206 | +> |
| 207 | +**App for cross-account** This mode is used where you have deployed the secrets in a separate account, the arns of the KMS key and secrets need to be passed into the __CrossStackConfig__ field, It is easiest to have created the secrets in the other account using the ** Secrest for cross-account** mode, as the output can simply copied and pasted into the above field. |
| 208 | + |
| 209 | +> [!CAUTION] |
| 210 | +> If you want to use your own existing secrets then provide them as a comma separated list in the __CrossStackConfig__ field in the following order: |
| 211 | +> __GoogleCredentials ARN__,__GoogleAdminEmail ARN__,__SCIMEndpoint ARN__,__SCIMAccessToken ARN__,__Region ARN__,__IdentityStoreID ARN__,__KMS Key ARN__ |
| 212 | +
|
| 213 | +> [!IMPORTANT] |
| 214 | +> Be sure to allow access to the key and secrets in their respective policies to the role __SSOSyncAppRole__ in the app account. |
| 215 | +
|
| 216 | +**Secrets only** This mode creates a set of secrets but does not deploy the app itself, it requires the app is deployed in that same account using the **App only** mode. This allows for decoupling of the secrets and the app. |
| 217 | + |
| 218 | +**Secrets for cross-account** This mode creates a set of secrets and KMS key but does not deploy the app itself, this is for use with an app stack, deployed using the **App for cross-account** mode. This allows for a single set of secrets to be shared with multipl app instance for testing, and improve secrets security. |
180 | 219 |
|
181 | 220 | ## SAM |
182 | 221 |
|
|
0 commit comments