Openstack keystone user token vs service token

In OpenStack Keystone, there are two types of tokens: user tokens and service tokens.

  1. User Tokens:
    • User tokens are authentication tokens issued to end-users of the OpenStack services. They are obtained by users when they authenticate with Keystone using their credentials, such as username and password. User tokens are short-lived and typically have an expiration time, after which they become invalid and need to be refreshed or re-authenticated. User tokens are used to access and interact with various OpenStack services, such as Nova (Compute), Neutron (Networking), Cinder (Block Storage), and others. When a user makes a request to any OpenStack service, the user token is included in the request headers to authenticate and authorize the user’s access to the requested resource.
    • The specific options related to user tokens are usually found in the [token] section of the configuration file ‘ /etc/keystone/keystone.conf‘. Here are some common configuration options related to user tokens:
      • provider: Specifies the token provider to use. The default provider is uuid, which generates UUID-based tokens. Other providers, such as fernet, may be available depending on your Keystone installation.
      • expiration: Specifies the duration of token validity in seconds. After this period, the token will expire and authentication will be required again. The default value is usually 86400 seconds (24 hours).
      • caching: Enables or disables token caching. When enabled, Keystone can cache tokens to improve performance. The default value is usually true.
      • cache_time: Specifies the duration in seconds for caching tokens. This option is only effective if caching is enabled. The default value is usually 600 seconds (10 minutes).
      • revoke_by_id: Enables or disables token revocation by token ID. If set to true, Keystone can revoke tokens using their ID. The default value is usually true.
      • revoke_by_expiration: Enables or disables token revocation by expiration. If set to true, Keystone can automatically revoke expired tokens. The default value is usually true.
      • revoke_events_ttl: Specifies the duration in seconds for storing token revocation events. After this period, expired events will be purged from the database. The default value is usually 86400 seconds (24 hours).
  2. Service Tokens:
    • Service tokens, on the other hand, are used for inter-service communication within the OpenStack environment. They are issued to OpenStack services themselves, rather than end-users. Service tokens are typically long-lived and don’t have an expiration time, as they are primarily used for internal communication between services. Service tokens are used to authorize service-to-service requests within OpenStack. For example, when the Nova service needs to communicate with the Neutron service to provision network resources for a new virtual machine, it presents its service token to Keystone to authenticate itself. Once authenticated, the Nova service can securely communicate with the Neutron service to perform the necessary operations.
    • Here are some relevant options related to service tokens:
      • [token] section:
        • provider: Specifies the token provider to be used. The default value is fernet.
        • expiration: Defines the time in seconds for which a service token is valid. The default value is 86400 seconds (24 hours).
        • hash_algorithm: Specifies the hash algorithm used for hashing service tokens. The default value is md5.
        • hash_rounds: Specifies the number of hash rounds performed on service tokens. The default value is 65535.
        • revoke_by_id: Specifies whether to enable or disable token revocation by token ID. The default value is True.
      • [tokenless_auth] section:
        • enabled: Specifies whether tokenless authentication is enabled or not. If set to False, service tokens are required for authentication. The default value is True.
      • [security_compliance] section:
        • validate_token_bind: Specifies whether token binding should be enforced or not. The default value is permissive. Other possible values are strict and disabled.

In summary, user tokens are obtained by end-users during authentication and are used to access OpenStack services on their behalf. Service tokens, on the other hand, are used by OpenStack services for internal communication and are typically long-lived.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top