SupportConsoleDevelopersStart a trialContact

Chapter 4. Configuring action log storage for Elasticsearch and Splunk

By default, usage logs are stored in the Red Hat Quay database and exposed through the web UI on organization and repository levels.

Appropriate administrative privileges are required to see log entries. For deployments with a large amount of logged operations, you can store the usage logs in Elasticsearch and Splunk instead of the Red Hat Quay database backend.

To store Red Hat Quay action logs in Elasticsearch, you can update the LOGS_MODEL settings in your config.yaml file and restart the registry. Usage logs remain available in the web UI for repositories and organizations.

Note

To configure action log storage for Elasticsearch, you must provide your own Elasticsearch stack; Red Hat Quay does not include Elasticsearch as a customizable component.

Procedure

  1. Obtain an Elasticsearch account.

  2. Update your Red Hat Quay config.yaml file to include the following information: 

    # ...
LOGS_MODEL: elasticsearch
LOGS_MODEL_CONFIG:
    producer: elasticsearch
    elasticsearch_config:
        host: http://<host.elasticsearch.example>:<port>
        port: 9200
        access_key: <access_key>
        secret_key: <secret_key>
        use_ssl: True
        index_prefix: <logentry>
        aws_region: <us-east-1>
# ...

    where:

    LOGS_MODEL
    Specifies the method for handling log data.
    LOGS_MODEL_CONFIG.producer
    Specifies either Elasticsearch or Kinesis to direct logs to an intermediate Kinesis stream on AWS. You need to configure your own pipeline to send logs from Kinesis to Elasticsearch, for example, Logstash.
    LOGS_MODEL_CONFIG.elasticsearch_config.host
    Specifies the hostname or IP address of the system providing the Elasticsearch service.
    LOGS_MODEL_CONFIG.elasticsearch_config.port
    Specifies the port number providing the Elasticsearch service on the host you just entered. Note that the port must be accessible from all systems running the Red Hat Quay registry. The default is TCP port 9200.
    LOGS_MODEL_CONFIG.elasticsearch_config.access_key
    Specifies the access key needed to gain access to the Elasticsearch service, if required.
    LOGS_MODEL_CONFIG.elasticsearch_config.secret_key
    Specifies the secret key needed to gain access to the Elasticsearch service, if required.
    LOGS_MODEL_CONFIG.elasticsearch_config.use_ssl
    Specifies whether to use SSL/TLS for Elasticsearch. Defaults to True.
    LOGS_MODEL_CONFIG.elasticsearch_config.index_prefix
    Specifies a prefix to attach to log entries.
    LOGS_MODEL_CONFIG.elasticsearch_config.aws_region
    Specifies the AWS region if you are running on AWS. Otherwise, leave it blank.

  3. Optional. If you are using Kinesis as your logs producer, you must include the following fields in your config.yaml file: 

        kinesis_stream_config:
        stream_name: <kinesis_stream_name>
        access_key: <aws_access_key>
        secret_key: <aws_secret_key>
        aws_region: <aws_region>

    where:

    kinesis_stream_config.stream_name
    Specifies the name of the Kinesis stream.
    kinesis_stream_config.access_key
    Specifies the name of the AWS access key needed to gain access to the Kinesis stream, if required.
    kinesis_stream_config.secret_key
    Specifies the name of the AWS secret key needed to gain access to the Kinesis stream, if required.
    kinesis_stream_config.aws_region
    Specifies the Amazon Web Services (AWS) region.
  4. Save your config.yaml file and restart your Red Hat Quay deployment.

4.2. Configuring action log storage for Splunk
Copy link

Splunk is an alternative to Elasticsearch for storing and analyzing Red Hat Quay action logs. You can forward logs directly to Splunk or to the Splunk HTTP Event Collector (HEC) during or after deployment.

To prepare Splunk for Red Hat Quay action log storage, you can install Splunk Enterprise and create an administrator username and password.

Procedure

  1. Create a Splunk account by navigating to Splunk and entering the required credentials.
  2. Navigate to the Splunk Enterprise Free Trial page, select your platform and installation package, and then click Download Now.
  3. Install the Splunk software on your machine. When prompted, create a username, for example, splunk_admin and password.
  4. After creating a username and password, a localhost URL will be provided for your Splunk deployment, for example, http://<sample_url>.remote.csb:8000/. Open the URL in your preferred browser.
  5. Log in with the username and password you created during installation. You are directed to the Splunk UI.

4.2.2. Generating a Splunk bearer token
Copy link

You can generate a Splunk bearer token for Red Hat Quay action log forwarding by using the Splunk UI or the CLI.

To create a Splunk bearer token for Red Hat Quay from the Splunk UI, you can enable token authentication and create a new token.

Prerequisites

  • You have installed Splunk and created a username.

Procedure

  1. On the Splunk UI, navigate to Settings Tokens.
  2. Click Enable Token Authentication.
  3. Ensure that Token Authentication is enabled by clicking Token Settings and selecting Token Authentication if necessary.
  4. Optional: Set the expiration time for your token. This defaults at 30 days.
  5. Click Save.
  6. Click New Token.
  7. Enter information for User and Audience.
  8. Optional: Set the Expiration and Not Before information.

  9. Click Create. Your token appears in the Token box. Copy the token immediately.

    Important

    If you close out of the box before copying the token, you must create a new token. The token in its entirety is not available after closing the New Token window.

To create a Splunk bearer token for Red Hat Quay from the CLI, you can enable token authentication and request a token with curl.

Prerequisites

  • You have installed Splunk and created a username.

Procedure

  1. In your CLI, enter the following CURL command to enable token authentication, passing in your Splunk username and password: 

    $ curl -k -u <username>:<password> -X POST <scheme>://<host>:<port>/services/admin/token-auth/tokens_auth -d disabled=false

  2. Create a token by entering the following CURL command, passing in your Splunk username and password. 

    $ curl -k -u <username>:<password> -X POST <scheme>://<host>:<port>/services/authorization/tokens?output_mode=json --data name=<username> --data audience=Users --data-urlencode expires_on=+30d
  3. Save the generated bearer token.

4.2.2.3. Generating an HEC ingest token
Copy link

To forward Red Hat Quay action logs to Splunk through the HTTP Event Collector (HEC), you can generate an HEC ingest token in the Splunk web UI or by using the Splunk REST API.

Note

Splunk HEC tokens are ingest-only and cannot search.

Prerequisites

  • You have installed Splunk and created a username.

Procedure

  1. To create an HEC token using the Splunk web UI:

    1. Log in to the Splunk via the web UI.
    2. Click Settings Data Inputs HTTP Event Collector.
    3. Click New Token.
    4. Name the token, for example, quay-hec, and select the target index, for example, quay_logs.
    5. Click Submit and copy the token value.

  2. To create an HEC token using the Splunk REST API:

    1. Enable HEC by entering the following command: 

      $ curl -k -u <username>:<password> \
 https://<splunk.example.com>:8089/servicesNS/admin/splunk_httpinput/data/inputs/http/http \
 -d "disabled=0"

    2. Create an HEC token by entering the following command: 

      $ curl -k -u <username>:<password> \
 "https://<splunk.example.com>:8089/servicesNS/admin/splunk_httpinput/data/inputs/http?output_mode=json" \
 -d "name=quay-hec" -d "index=quay_logs"

      Example output:

      {"entry":[{"content":{"token":"<your_bearer_token>"}}]}

4.2.3. Configuring Red Hat Quay to use Splunk
Copy link

To send Red Hat Quay action logs to Splunk or the Splunk HTTP Event Collector (HEC), you can add the Splunk settings to your config.yaml file and restart the registry.

Prerequisites

  • You have installed Splunk and created a username.
  • You have generated a Splunk bearer token.

Procedure

  1. Configure Red Hat Quay to use Splunk or the Splunk HTTP Event Collector (HEC).

    1. If opting to use Splunk, open your Red Hat Quay config.yaml file and add the following configuration fields: 

      # ...
LOGS_MODEL: splunk
LOGS_MODEL_CONFIG:
    producer: splunk
    splunk_config:
        host: http://<user_name>.remote.csb
        port: 8089
        bearer_token: <bearer_token>
        url_scheme: <http/https>
        verify_ssl: False
        index_prefix: <splunk_log_index_name>
        ssl_ca_path: <location_to_ssl-ca-cert.pem>
        search_timeout: 60
        max_results: 10000
        export_batch_size: 5000
# ...

      where:

      LOGS_MODEL_CONFIG.splunk_config.host
      Specifies the Splunk cluster endpoint.
      LOGS_MODEL_CONFIG.splunk_config.port
      Specifies the Splunk management cluster endpoint port. Differs from the Splunk GUI hosted port. Can be found on the Splunk UI under Settings Server Settings General Settings.
      LOGS_MODEL_CONFIG.splunk_config.bearer_token
      Specifies the generated bearer token for Splunk.
      LOGS_MODEL_CONFIG.splunk_config.url_scheme
      Specifies the URL scheme for access the Splunk service. If Splunk is configured to use TLS/SSL, this must be https.
      LOGS_MODEL_CONFIG.splunk_config.verify_ssl
      Specifies whether to enable TLS/SSL. Defaults to True.
      LOGS_MODEL_CONFIG.splunk_config.index_prefix
      Specifies the Splunk index prefix. Can be a new, or used, index. Can be created from the Splunk UI.
      LOGS_MODEL_CONFIG.splunk_config.ssl_ca_path
      Specifies the relative container path to a single .pem file containing a certificate authority (CA) for TLS/SSL validation.
      LOGS_MODEL_CONFIG.splunk_config.search_timeout
      Specifies the timeout for Splunk search queries in seconds. Increase for slow Splunk clusters or complex queries.
      LOGS_MODEL_CONFIG.splunk_config.max_results
      Specifies the maximum number of results to return per search query. Larger values require more memory.
      LOGS_MODEL_CONFIG.splunk_config.export_batch_size
      Specifies the batch size for log export operations.

    2. If opting to use Splunk HEC, open your Red Hat Quay config.yaml file and add the following configuration fields: 

      # ...
LOGS_MODEL: splunk
LOGS_MODEL_CONFIG:
  producer: splunk_hec
  splunk_hec_config:
    host: prd-p-aaaaaq.splunkcloud.com
    port: 8088
    hec_token: 12345678-1234-1234-1234-1234567890ab
    url_scheme: https
    verify_ssl: False
    index: quay
    splunk_host: quay-dev
    splunk_sourcetype: quay_logs
    timeout: 10
    search_token: <bearer_token>
    search_host: <splunk.example.com>
    search_port: 8089
    search_timeout: 60
    max_results: 10000
    export_batch_size: 5000
# ...

      where:

      LOGS_MODEL_CONFIG.producer
      Specifies splunk_hec when configuring Splunk HEC.
      LOGS_MODEL_CONFIG.splunk_hec_config
      Specifies the logs model configuration for Splunk HTTP Event Collector action logs configuration.
      LOGS_MODEL_CONFIG.splunk_hec_config.host
      Specifies the Splunk cluster endpoint.
      LOGS_MODEL_CONFIG.splunk_hec_config.port
      Specifies the Splunk management cluster endpoint port.
      LOGS_MODEL_CONFIG.splunk_hec_config.hec_token
      Specifies the HEC token for Splunk.
      LOGS_MODEL_CONFIG.splunk_hec_config.url_scheme
      Specifies the URL scheme for access the Splunk service. If Splunk is behind SSL/TLS, must be https.
      LOGS_MODEL_CONFIG.splunk_hec_config.verify_ssl
      Specifies whether to enable (true) or disable (false) SSL/TLS verification for HTTPS connections.
      LOGS_MODEL_CONFIG.splunk_hec_config.index
      Specifies the Splunk index to use.
      LOGS_MODEL_CONFIG.splunk_hec_config.splunk_host
      Specifies the host name to log this event.
      LOGS_MODEL_CONFIG.splunk_hec_config.splunk_sourcetype
      Specifies the name of the Splunk sourcetype to use.
      LOGS_MODEL_CONFIG.splunk_hec_config.timeout
      Specifies the timeout in seconds for HTTP requests to the Splunk HEC endpoint. Prevents requests from hanging indefinitely when Splunk is unresponsive.
      LOGS_MODEL_CONFIG.splunk_hec_config.search_token
      Specifies an optional bearer token for the Splunk search API. Required because HEC tokens are ingest-only and cannot search.
      LOGS_MODEL_CONFIG.splunk_hec_config.search_host
      Specifies the Splunk management host for the search API. Defaults to the HEC host if not specified.
      LOGS_MODEL_CONFIG.splunk_hec_config.search_port
      Specifies the Splunk management port for the search API. Defaults to 8089 if not specified.
      LOGS_MODEL_CONFIG.splunk_hec_config.search_timeout
      Specifies the timeout for Splunk search queries in seconds. Increase for slow Splunk clusters or complex queries.
      LOGS_MODEL_CONFIG.splunk_hec_config.max_results
      Specifies the maximum number of results to return per search query. Larger values require more memory.
      LOGS_MODEL_CONFIG.splunk_hec_config.export_batch_size
      Specifies the batch size for log export operations.

  2. If you are configuring ssl_ca_path, you must configure the SSL/TLS certificate so that Red Hat Quay trusts it.

    1. If you are using a standalone deployment of Red Hat Quay, SSL/TLS certificates can be provided by placing the certificate file inside of the extra_ca_certs directory, or inside of the relative container path and specified by ssl_ca_path.

    2. If you are using the Red Hat Quay Operator, create a config bundle secret, including the certificate authority (CA) of the Splunk server. For example: 

      $ oc create secret generic --from-file config.yaml=./config_390.yaml --from-file extra_ca_cert_splunkserver.crt=./splunkserver.crt config-bundle-secret

      Specify the conf/stack/extra_ca_certs/splunkserver.crt file in your config.yaml. For example: 

      # ...
LOGS_MODEL: splunk
LOGS_MODEL_CONFIG:
    producer: splunk
    splunk_config:
        host: ec2-12-345-67-891.us-east-2.compute.amazonaws.com
        port: 8089
        bearer_token: eyJra
        url_scheme: https
        verify_ssl: true
        index_prefix: quay123456
        ssl_ca_path: conf/stack/splunkserver.crt
# ...

4.2.4. Creating an action log
Copy link

To verify that Red Hat Quay is forwarding action logs to Splunk, you can create a robot account in an organization and search the Splunk index for the forwarded JSON log entries.

Prerequisites

  • You have installed Splunk and created a username.
  • You have generated a Splunk bearer token.
  • You have configured your Red Hat Quay config.yaml file to enable Splunk.

Procedure

  1. Log in to your Red Hat Quay deployment.
  2. Click on the name of the organization that you use to create an action log for Splunk.
  3. In the navigation pane, click Robot Accounts Create Robot Account.
  4. When prompted, enter a name for the robot account, for example splunkrobotaccount, then click Create robot account.
  5. On your browser, open the Splunk UI.
  6. Click Search and Reporting.

  7. In the search bar, enter the name of your index, for example, <splunk_log_index_name> and press Enter.

    The search results populate on the Splunk UI. Logs are forwarded in JSON format. A response might look similar to the following: 

    {
  "log_data": {
    "kind": "authentication",
    "account": "quayuser123",
    "performer": "John Doe",
    "repository": "projectQuay",
    "ip": "192.168.1.100",
    "metadata_json": {...},
    "datetime": "2024-02-06T12:30:45Z"
  }
}

    where:

    kind
    Specifies the type of log event. In this example, authentication indicates that the log entry relates to an authentication event.
    account
    Specifies the user account involved in the event.
    performer
    Specifies the individual who performed the action.
    repository
    Specifies the repository associated with the event.
    ip
    Specifies the IP address from which the action was performed.
    metadata_json
    Specifies additional metadata related to the event, when present.
    datetime
    Specifies the timestamp of when the event occurred.

To view Splunk audit logs in the Red Hat Quay UI, you can configure Splunk or Splunk HEC credentials in your config.yaml file and restart the registry. Then open the Logs panel for an organization, repository, or superuser view.

Prerequisites

  • You have created an hec_token.

    Note

    For the HEC producer, two tokens are required: hec_token for writing logs and search_token for reading logs in the UI. The search_token is a bearer token (the same type you create when generating a Splunk bearer token). HEC tokens are ingest-only and cannot run searches.

  • You have configured Red Hat Quay to forward action logs to Splunk.

Procedure

  1. Update your config.yaml file:

    1. To display Splunk SDK audit logs on the Red Hat Quay UI, use the following reference: 

      LOGS_MODEL: splunk
LOGS_MODEL_CONFIG:
  producer: splunk
  splunk_config:
    host: <splunk.example.com>
    port: 8089
    bearer_token: <your_bearer_token>
    url_scheme: https
    verify_ssl: false
    index_prefix: quay_logs
    search_timeout: 60
    max_results: 10000
    export_batch_size: 5000

      where:

      LOGS_MODEL_CONFIG.splunk_config.host
      Specifies the host name of your Splunk instance.
      LOGS_MODEL_CONFIG.splunk_config.bearer_token
      Specifies the bearer token you generated for Splunk.
      LOGS_MODEL_CONFIG.splunk_config.index_prefix
      Specifies the Splunk index prefix.

    2. To display Splunk HEC logs on the Red Hat Quay UI, include the generated search_token and hec_token. For example: 

      LOGS_MODEL: splunk
LOGS_MODEL_CONFIG:
  producer: splunk_hec
  splunk_hec_config:
    host: <splunk.example.com>
    port: 8088
    hec_token: <your_hec_token>
    search_token: <your_bearer_token>
    url_scheme: https
    verify_ssl: true
    ssl_ca_path: conf/stack/ca.pem
    index: quay_logs
    splunk_host: <quay-server.example.com>
    splunk_sourcetype: access_combined
    timeout: 10
    search_host: <splunk.example.com>
    search_port: 8089
    search_timeout: 60
    max_results: 10000
    export_batch_size: 5000

      where:

      LOGS_MODEL_CONFIG.splunk_hec_config.host
      Specifies the host name of your Splunk instance (used for both the HEC endpoint and the search API).
      LOGS_MODEL_CONFIG.splunk_hec_config.port
      Specifies the port number for the Splunk HEC endpoint.
      LOGS_MODEL_CONFIG.splunk_hec_config.hec_token
      Specifies the HEC token you generated for Splunk.
      LOGS_MODEL_CONFIG.splunk_hec_config.search_token
      Specifies the bearer token you generated for Splunk search. This field is optional.
      LOGS_MODEL_CONFIG.splunk_hec_config.splunk_host
      Specifies the host name of your Red Hat Quay instance.
  2. Restart your Red Hat Quay instance to apply the changes.

  3. Push an example image to your Red Hat Quay instance to generate an audit log by entering the following command. Note that you can push to an organization or a repository. 

    $ podman push <quay-server.example.com>/<organization_name>/busybox:test

  4. On the Red Hat Quay UI, open the Logs view in one of these places:

    • Organizations <organization_name> Logs
    • Repositories <organization_name> / <repository_name> Logs
    • Superuser Usage Logs

Results

  • The busybox:test Splunk audit is available.

4.3. Understanding usage logs
Copy link

By default, Red Hat Quay stores usage logs in its database and shows them in the web UI. You can query those logs in PostgreSQL and map action types by kind_id.

Usage logs appear at the organization and repository levels, and in the Superuser Admin Panel. Database logs capture a wide range of events in Red Hat Quay, such as account plan changes, user actions, and general operations. Log entries include information such as the action performed (kind_id), the user who performed the action (account_id or performer_id), the timestamp (datetime), and other relevant data associated with the action (metadata_json).

4.3.1. Viewing database logs
Copy link

To view repository usage logs stored in the Red Hat Quay PostgreSQL database, you can query the logentry tables with the psql CLI tool.

Prerequisites

  • You have administrative privileges.
  • You have installed the psql CLI tool.

Procedure

  1. Enter the following command to log in to your Red Hat Quay PostgreSQL database: 

    $ psql -h <quay-server.example.com> -p 5432 -U <user_name> -d <database_name>

    Example output

    psql (16.1, server 13.7)
Type "help" for help.

  2. Optional. Enter the following command to display the tables list of your PostgreSQL database: 

    quay=> \dt

    Example output

                       List of relations
 Schema |            Name            | Type  |  Owner
--------+----------------------------+-------+----------
 public | logentry                   | table | quayuser
 public | logentry2                  | table | quayuser
 public | logentry3                  | table | quayuser
 public | logentrykind               | table | quayuser
...

  3. Enter the following command to return a list of repository_ids that are required to return log information: 

    quay=> SELECT id, name FROM repository;

    Example output

     id |        name
----+---------------------
  3 | new_repository_name
  6 | api-repo
  7 | busybox
...

  4. Enter the following command to use the logentry3 relation to show log information about one of your repositories: 

    SELECT * FROM logentry3 WHERE repository_id = <repository_id>;

    Example output

     id | kind_id | account_id | performer_id | repository_id | datetime | ip |    metadata_json

 59 | 14 | 2 | 1 | 6 | 2024-05-13 15:51:01.897189 | 192.168.1.130 | {"repo": "api-repo", "namespace": "test-org"}

    In this example, the following information is returned: 

    {
  "log_data": {
    "id": 59
    "kind_id": "14",
    "account_id": "2",
    "performer_id": "1",
    "repository_id": "6",
    "ip": "192.168.1.100",
    "metadata_json": {"repo": "api-repo", "namespace": "test-org"}
    "datetime": "2024-05-13 15:51:01.897189"
  }
}

    where:

    id
    Specifies the unique identifier for the log entry.
    kind_id
    Specifies the action that was performed. In this example, 14 maps to creating a repository (create_repo).
    account_id
    Specifies the account that performed the action.
    performer_id
    Specifies the performer of the action.
    repository_id
    Specifies the repository that the action was performed on. In this example, 6 correlates to the api-repo repository from the previous step.
    ip
    Specifies the IP address where the action was performed.
    metadata_json
    Specifies metadata information, including the name of the repository and its namespace.
    datetime
    Specifies the time when the action was performed.

4.3.2. Log entry kind_ids
Copy link

The kind_id value in a Red Hat Quay usage log entry identifies the type of action that was recorded. You can use this table to map each kind_id to its action name and description.

kind_idActionDescription

1

account_change_cc

Change of credit card information.

2

account_change_password

Change of account password.

3

account_change_plan

Change of account plan.

4

account_convert

Account conversion.

5

add_repo_accesstoken

Adding an access token to a repository.

6

add_repo_notification

Adding a notification to a repository.

7

add_repo_permission

Adding permissions to a repository.

8

add_repo_webhook

Adding a webhook to a repository.

9

build_dockerfile

Building a Dockerfile.

10

change_repo_permission

Changing permissions of a repository.

11

change_repo_visibility

Changing the visibility of a repository.

12

create_application

Creating an application.

13

create_prototype_permission

Creating permissions for a prototype.

14

create_repo

Creating a repository.

15

create_robot

Creating a robot (service account or bot).

16

create_tag

Creating a tag.

17

delete_application

Deleting an application.

18

delete_prototype_permission

Deleting permissions for a prototype.

19

delete_repo

Deleting a repository.

20

delete_repo_accesstoken

Deleting an access token from a repository.

21

delete_repo_notification

Deleting a notification from a repository.

22

delete_repo_permission

Deleting permissions from a repository.

23

delete_repo_trigger

Deleting a repository trigger.

24

delete_repo_webhook

Deleting a webhook from a repository.

25

delete_robot

Deleting a robot.

26

delete_tag

Deleting a tag.

27

manifest_label_add

Adding a label to a manifest.

28

manifest_label_delete

Deleting a label from a manifest.

29

modify_prototype_permission

Modifying permissions for a prototype.

30

move_tag

Moving a tag.

31

org_add_team_member

Adding a member to a team.

32

org_create_team

Creating a team within an organization.

33

org_delete_team

Deleting a team within an organization.

34

org_delete_team_member_invite

Deleting a team member invitation.

35

org_invite_team_member

Inviting a member to a team in an organization.

36

org_remove_team_member

Removing a member from a team.

37

org_set_team_description

Setting the description of a team.

38

org_set_team_role

Setting the role of a team.

39

org_team_member_invite_accepted

Acceptance of a team member invitation.

40

org_team_member_invite_declined

Declining of a team member invitation.

41

pull_repo

Pull from a repository.

42

push_repo

Push to a repository.

43

regenerate_robot_token

Regenerating a robot token.

44

repo_verb

Generic repository action (specifics might be defined elsewhere).

45

reset_application_client_secret

Resetting the client secret of an application.

46

revert_tag

Reverting a tag.

47

service_key_approve

Approving a service key.

48

service_key_create

Creating a service key.

49

service_key_delete

Deleting a service key.

50

service_key_extend

Extending a service key.

51

service_key_modify

Modifying a service key.

52

service_key_rotate

Rotating a service key.

53

setup_repo_trigger

Setting up a repository trigger.

54

set_repo_description

Setting the description of a repository.

55

take_ownership

Taking ownership of a resource.

56

update_application

Updating an application.

57

change_repo_trust

Changing the trust level of a repository.

58

reset_repo_notification

Resetting repository notifications.

59

change_tag_expiration

Changing the expiration date of a tag.

60

create_app_specific_token

Creating an application-specific token.

61

revoke_app_specific_token

Revoking an application-specific token.

62

toggle_repo_trigger

Toggling a repository trigger on or off.

63

repo_mirror_enabled

Enabling repository mirroring.

64

repo_mirror_disabled

Disabling repository mirroring.

65

repo_mirror_config_changed

Changing the configuration of repository mirroring.

66

repo_mirror_sync_started

Starting a repository mirror sync.

67

repo_mirror_sync_failed

Repository mirror sync failed.

68

repo_mirror_sync_success

Repository mirror sync succeeded.

69

repo_mirror_sync_now_requested

Immediate repository mirror sync requested.

70

repo_mirror_sync_tag_success

Repository mirror tag sync succeeded.

71

repo_mirror_sync_tag_failed

Repository mirror tag sync failed.

72

repo_mirror_sync_test_success

Repository mirror sync test succeeded.

73

repo_mirror_sync_test_failed

Repository mirror sync test failed.

74

repo_mirror_sync_test_started

Repository mirror sync test started.

75

change_repo_state

Changing the state of a repository.

76

create_proxy_cache_config

Creating proxy cache configuration.

77

delete_proxy_cache_config

Deleting proxy cache configuration.

78

start_build_trigger

Starting a build trigger.

79

cancel_build

Canceling a build.

80

org_create

Creating an organization.

81

org_delete

Deleting an organization.

82

org_change_email

Changing organization email.

83

org_change_invoicing

Changing organization invoicing.

84

org_change_tag_expiration

Changing organization tag expiration.

85

org_change_name

Changing organization name.

86

user_create

Creating a user.

87

user_delete

Deleting a user.

88

user_disable

Disabling a user.

89

user_enable

Enabling a user.

90

user_change_email

Changing user email.

91

user_change_password

Changing user password.

92

user_change_name

Changing user name.

93

user_change_invoicing

Changing user invoicing.

94

user_change_tag_expiration

Changing user tag expiration.

95

user_change_metadata

Changing user metadata.

96

user_generate_client_key

Generating a client key for a user.

97

login_success

Successful login.

98

logout_success

Successful logout.

99

permanently_delete_tag

Permanently deleting a tag.

100

autoprune_tag_delete

Auto-pruning tag deletion.

101

create_namespace_autoprune_policy

Creating namespace auto-prune policy.

102

update_namespace_autoprune_policy

Updating namespace auto-prune policy.

103

delete_namespace_autoprune_policy

Deleting namespace auto-prune policy.

104

login_failure

Failed login attempt.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top