此内容没有您所选择的语言版本。
Chapter 15. Using the Multicloud Object Gateway’s Security Token Service to assume the role of another user
Multicloud Object Gateway (MCG) provides support to a security token service (STS) similar to the one provided by Amazon Web Services.
To allow other users to assume the role of a certain user, you need to assign a role configuration to the user. You can manage the configuration of roles using the MCG CLI tool.
The following example shows role configuration that allows two MCG users (assumer@mcg.test and assumer2@mcg.test) to assume a certain user’s role:
'{"role_name": "AllowTwoAssumers", "assume_role_policy": {"version": "2012-10-17", "statement": [ {"action": ["sts:AssumeRole"], "effect": "allow", "principal": ["assumer@mcg.test", "assumer2@mcg.test"]}]}}'
'{"role_name": "AllowTwoAssumers", "assume_role_policy": {"version": "2012-10-17", "statement": [ {"action": ["sts:AssumeRole"], "effect": "allow", "principal": ["assumer@mcg.test", "assumer2@mcg.test"]}]}}'
Assign the role configuration by using the MCG CLI tool.
mcg sts assign-role --email <assumed user's username> --role_config '{"role_name": "AllowTwoAssumers", "assume_role_policy": {"version": "2012-10-17", "statement": [ {"action": ["sts:AssumeRole"], "effect": "allow", "principal": ["assumer@mcg.test", "assumer2@mcg.test"]}]}}'mcg sts assign-role --email <assumed user's username> --role_config '{"role_name": "AllowTwoAssumers", "assume_role_policy": {"version": "2012-10-17", "statement": [ {"action": ["sts:AssumeRole"], "effect": "allow", "principal": ["assumer@mcg.test", "assumer2@mcg.test"]}]}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Collect the following information before proceeding to assume the role as it is needed for the subsequent steps:
- The access key ID and secret access key of the assumer (the user who assumes the role)
The MCG STS endpoint, which can be retrieved by using the command:
oc -n openshift-storage get route
$ oc -n openshift-storage get routeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - The access key ID of the assumed user.
-
The value of the
role_namevalue in your role configuration. - A name of your choice for the role session
- After the configuration role is ready, assign it to the appropriate user (fill with the data described in the previous step) -
AWS_ACCESS_KEY_ID=<aws-access-key-id> AWS_SECRET_ACCESS_KEY=<aws-secret-access-key1> aws --endpoint-url <mcg-sts-endpoint> sts assume-role --role-arn arn:aws:sts::<assumed-user-access-key-id>:role/<role-name> --role-session-name <role-session-name>
AWS_ACCESS_KEY_ID=<aws-access-key-id> AWS_SECRET_ACCESS_KEY=<aws-secret-access-key1> aws --endpoint-url <mcg-sts-endpoint> sts assume-role --role-arn arn:aws:sts::<assumed-user-access-key-id>:role/<role-name> --role-session-name <role-session-name>
Adding --no-verify-ssl might be necessary depending on your cluster’s configuration.
The resulting output contains the access key ID, secret access key, and session token that can be used for executing actions while assuming the other user’s role.
You can use the credentials generated after the assume role steps as shown in the following example:
AWS_ACCESS_KEY_ID=<aws-access-key-id> AWS_SECRET_ACCESS_KEY=<aws-secret-access-key1> AWS_SESSION_TOKEN=<session token> aws --endpoint-url <mcg-s3-endpoint> s3 ls
AWS_ACCESS_KEY_ID=<aws-access-key-id> AWS_SECRET_ACCESS_KEY=<aws-secret-access-key1> AWS_SESSION_TOKEN=<session token> aws --endpoint-url <mcg-s3-endpoint> s3 ls