mint is STUPS’ secret distributor and rotator. Its main task is to constantly rotate service passwords or API keys and provide the secrets to the actual applications.

How it works


Step 0

A developer has to specify which AWS account the credentials of their application should get distributed to.

Step 1 + 2

At first, mint makes sure that every registered application has its own ‘service user’ in the IAM solution. It then also deletes all users that are either inactive or do not even exist in Kio.

Step 3 + 4

mint will regularly rotate the passwords and OAuth 2.0 credentials for all service users. The new secrets are then stored in S3 buckets in the owning team’s AWS accounts, where each registered application has one directory. mint has write access to those directories for updating the secrets but no read access.

Step 5

Applications can download their current secrets from their directory on S3 using their instance profiles. A team has to configure access to the correct credentials for their server. It is the application owner’s responsibility to assign the correct IAM profiles to the actual EC2 instances. berry can help with the permanent retrieval of the application’s secrets.

The following picture demonstrates the exchange over S3:


API for applications

mint stores all credentials of an application in a directory in S3. If you know in which S3 bucket mint stores everything, you can construct the correct URLs to it:

The ‘user.json’ contains username and password of the service user. The ‘client.json’ contains the OAuth 2.0 client credentials. You should download the files via the AWS SDKs but you could also construct the HTTP request yourself according to the Amazon documentation. The two files have the following content:


    "application_username": "abc",
    "application_password": "xyz"


    "client_id": "foo",
    "client_secret": "bar"

Look at berry for automated download of these files for your application. Remember that these files change regularly. See also Taupage, which already integrates berry and provides the credentials files to your Docker image on the local filesystem.


In order to access other OAuth 2.0 protected services with your application, you need an access token. If your IAM solution supports the Resource Owner Password Credentials Grant, then you can get an access token for yourself with the above credentials:

$ curl -u $client_id:$client_secret \
    -d "grant_type=password&username=$application_username&password=$application_password&scope=cn+uid" \