Rokku项目的STS服务:https://github.com/ing-bank/rokku
STS stands for Short Token Service. The Rokku STS performs operations that are specific to managing service tokens.
For a higher level view of purpose of the Rokku STS service, please view the Rokku project.
The Rokku STS simulates the following STS actions:
This is the internal endpoint that is exposed:
Checks if a user credentials are active
/isCredentialActive?accessKey=userAccessKey&sessionToken=userSessionToken
Response status:
OK
{
"userName": "testuser",
"userGroups": "testGroup",
"accessKey": "userAccessKey",
"secretKey": "userSercretKey",
"userRole": "userRole"
}
To get a quickstart on running the Rokku STS, you’ll need the following:
Launch the Docker images which contain the dependencies for Rokku STS:
docker-compose up --build --force-recreate
When the docker services are up and running, you can start the Rokku STS:
sbt run
Have fun requesting tokens
The STS service is dependant on two services:
docker run -p 12345:12345 wbaa/rokku-sts:latest
to get the credential you need to provide a valid token in on of the places:
Authorization Bearer valid
X-Authorization-Token: valid
WebIdentityToken=valid
http://localhost:12345?Action=GetSessionToken
returns:
<GetSessionTokenResponse>
<GetSessionTokenResult>
<Credentials>
<SessionToken>
okSessionToken
</SessionToken>
<SecretAccessKey>
secretKey
</SecretAccessKey>
<Expiration>2019-07-11T19:55:29.611Z</Expiration>
<AccessKeyId>okAccessKey</AccessKeyId>
</Credentials>
</GetSessionTokenResult>
<ResponseMetadata>
<RequestId>58c5dbae-abef-11e0-8cfe-09039844ac7d</RequestId>
</ResponseMetadata>
</GetSessionTokenResponse>
http://localhost:12345?Action=AssumeRole&RoleArn=arn
iam:
role/admin&RoleSessionName=test
returns:
<AssumeRoleResponse>
<AssumeRoleResult>
<AssumedRoleUser>
<Arn>arn:aws:iam::account-id:role/admin/test</Arn>
<AssumedRoleId>id:test</AssumedRoleId>
</AssumedRoleUser>
<Credentials>
<SessionToken>okSessionToken</SessionToken>
<SecretAccessKey>secretKey</SecretAccessKey>
<Expiration>2019-10-07T20:08:57.450Z</Expiration>
<AccessKeyId>okAccessKey</AccessKeyId>
</Credentials>
</AssumeRoleResult>
<ResponseMetadata>
<RequestId>4265be0e-6246-4e3a-af72-b1a7cc997a94</RequestId>
</ResponseMetadata>
</AssumeRoleResponse>
the dev keycloak docker has a userone
who has the admin role.
http://localhost:12345/isCredentialActive?accessKey=okAccessKey&sessionToken=okSessionToken
returns status OK or Forbidden
NOTE: since EP is protected with token, you may need to add header with token to access isCredentialsActive endpoint
Default token that should match settings from test reference.conf file
-H "Authorization: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzZXJ2aWNlIjoicm9ra3UiLCJpc3MiOiJyb2trdSJ9.aCpyvC53lWdF_IOdZQp0fO8W4tH_LeK3vQcIvt5W1-0"
aws sts get-session-token --endpoint-url http://localhost:12345 --region localhost --token-code validToken
aws sts assume-role --role-arn arn:aws:iam::account-id:role/admin --role-session-name testrole --endpoint-url http://localhost:12345 --token-code validToken
STS allows users with the KEYCLOAK_NPA_ROLE
to be registered as NPAs. Only these users will have access to the /npa/*
endpoints.
When a user is registered as an NPA it can authenticate itself without the need of a session token from keycloak.
If the user already exists and aws credentials are issued for him then this operation will not be allowed and the request will
return a 409 Conflict.
curl -X POST "127.0.0.1:12345/npa/registry" -H "Authorization: Bearer $keycloak_token_session"
The response of the above request will be of the form
{
"accessKey": "the-npa-access-key",
"secretKey": "the-npa-secret-key"
}
curl -X GET "127.0.0.1:12345/npa/credentials" -H "Authorization: Bearer $keycloak_token_session"
The response of the above request will be of the form
{
"accessKey": "the-npa-access-key",
"secretKey": "the-npa-secret-key"
}
STS allows NPA (non personal account) access, in cases where client is not able to authenticate
with Keycloak server.
In order to notify STS that user is NPA user, below steps needs to be done:
User needs to be in administrator groups (user groups are taken from Keycloak)
Check settings of the value STS_ADMIN_GROUPS
in application.conf and set groups accordingly. Config accepts
coma separated string: “testgroup, othergroup”
A safe needs to exists with the correct name in vault, otherwise secrets will not be written to vault (404 in logs is an indication of that)
Use postman or other tool of choice to send x-www-form-urlencoded values:
npaAccount = value
safeName = vaule
awsAccessKey = value
awsSecretKey = value
as POST:
curl -X POST \
-d "npaAccount=${NPA_ACCOUNT}&safeName=${SAFE_NAME}&awsAccessKey=${NPA_ACCESS_KEY}&awsSecretKey=${NPA_SECRET_KEY}" \
-H "Authorization: Bearer ${KEYCLOAK_TOKEN}" \
http://127.0.0.1:12345/admin/npa
NPA user access key and account names must be unique, otherwise adding NPA will fail.
User must also:
When accessing Rokku with aws cli or sdk, just export AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY
with NO AWS_SESSION_TOKEN
STS user account details are taken from Keycloak, but additionally one can mark user account as disabled in Rokku-STS
by running:
Enable:
curl -H "Authorization: Bearer ${KEYCLOAK_TOKEN}" -X PUT http://localhost:12345/admin/account/{USER_NAME}/enable
Disable:
curl -H "Authorization: Bearer ${KEYCLOAK_TOKEN}" -X PUT http://localhost:12345/admin/account/{USER_NAME}/disable
User needs to be in administrator groups (user groups are taken from Keycloak). Check settings of the value STS_ADMIN_GROUPS
in application.conf and set groups accordingly.
If you plan to run rokku-sts in non-dev mode, make sure you at least set ENV value or edit application.conf
STS_MASTER_KEY = "radomKeyString"