Available since MOSK 22.4
Application credentials is a mechanism in the MOSK Identity service that enables application automation tools, such as shell scripts, Terraform modules, Python programs, and others, to securely perform various actions in the cloud API in order to deploy and manage application components.
Application credentials is a modern alternative to the legacy approach where every application owner had to request several technical user accounts to ensure their tools could authenticate in the cloud.
For the details on how to create and authenticate with application credentials, refer to manage-application-credentials.
Application credentials must be explicitly enabled for federated users¶
By default, cloud users logging in to the cloud through the Mirantis Container Cloud IAM or any external identity provider cannot use the application credentials mechanism.
An application credential is heavily tied to the account of the cloud user owning it. An application automation tool that is a consumer of the credential acts on behalf of the human user who created the credential. Each action that the application automation tool performs gets authorized against the permissions, including roles and groups, the user currently has.
The source of truth about a federated user permissions is the identity provider. This information gets temporary transferred to the cloud’s Identity service inside a token once the user authenticates. By default, if such a user creates an application credential and passes it to the automation tool, there is no data to validate the tool’s action on the user’s behalf.
However, a cloud operator can configure the
for an identity provider object to enable caching of its users authorization
data. The parameter defines for how long in minutes the information about
user permissions is preserved in the database after the user successfully
logs in to the cloud.
Authorization data caching has security implications. In case a federated user account is revoked or his permissions change in the identity provider, the cloud’s Identity service will still allow performing actions on the user behalf until the cached data expires or the user re-authenticates in the cloud.
authorization_ttl to, for example, 60 minutes for the
identity provider in Keystone:
Log in to the
kubectl -n openstack exec $(kubectl -n openstack get po -l application=keystone,component=client -oname) -ti -c keystone-client -- bash
Inside the Pod, run the following command:
openstack identity provider set keycloak --authorization-ttl 60
The ability to change
authorization_ttl using CLI in the
keystone-client Pod is available since MOSK 22.4.