Your aws\_cloudtrail declaration maps onto the target's native audit log; there is no separate cross-cloud trail to provision, because each cloud audits itself; LookupEvents reads history from that native log.
#### The native audit log Each cloud's native audit log is its own platform service, so the always-on-versus-policy-gated distinction is real rather than cosmetic. On **Google Cloud**, the trail maps onto **Cloud Audit Logs**. Admin Activity audit logs are always on and cannot be disabled; **Data Access** audit logs are opt-in per service and per type (`ADMIN_READ` / `DATA_READ` / `DATA_WRITE`) via `google_project_iam_audit_config`. Entries land in Cloud Logging under the `cloudaudit.googleapis.com` log names. On **OCI**, the trail maps onto OCI Audit , which is **always on for every tenancy** and records every API call automatically; `oci_audit_configuration` controls only the retention period, not whether auditing runs. On **Kubernetes**, the trail maps onto the **API-server audit policy and its backend**: a `kube-apiserver` audit policy (a cluster configuration, *not on by default*) decides which requests are recorded and at what level (`Metadata` / `Request` / `RequestResponse`), and an audit backend (a log file, or a webhook feeding a log store or SIEM) receives them. It is recorded **whenever your audit policy is in effect**. * **Google Cloud Audit Logs.** Admin Activity is always-on and cannot be disabled; Data Access is opt-in per service and type via `google_project_iam_audit_config`. * **OCI Audit:** always on for the tenancy, recording every API call; `oci_audit_configuration` sets only the retention period. * **Kubernetes API-server audit:** policy-gated: the `kube-apiserver` audit policy plus an audit backend, not on by default; recorded whenever your policy is in effect.
Each target's native audit log is its own platform service: always-on on Google Cloud and OCI, policy-gated on Kubernetes; your trail maps onto it.
#### Reading history (LookupEvents) `LookupEvents` is CloudTrail's history read: query the recent window of control-plane events, filtered by **LookupAttributes** such as `EventName`, `Username`, or `ResourceType`. Because the events are already recorded in the native audit log, a `LookupEvents` call maps onto a **query against that log**, and the recorded events are returned in the CloudTrail record shape. The query surface is the native log's. On **Google Cloud** the read runs against Cloud Logging (the Logs Explorer or the Logging API), filtering on `resource.type` and `protoPayload.methodName` under the `cloudaudit.googleapis.com` log names. On **OCI** it runs against the **OCI Audit query** (or Logging Analytics), filtering on event source and compartment. On **Kubernetes** it runs against the cluster's audit backend (the log store or SIEM the audit webhook feeds) using that store's filters. In every case the recorded events come back, but the attribute-filter surface is a subset of CloudTrail's LookupAttributes : you filter with what the native log's query language expresses, and the event body is the native audit entry mapped to a CloudTrail record. * **Google Cloud.** Cloud Logging, filtering on `resource.type` / `protoPayload.methodName` under `cloudaudit.googleapis.com`. * **OCI:** the OCI Audit query (or Logging Analytics), filtering on event source and compartment. * **Kubernetes:** the cluster's audit backend (the log store / SIEM the audit webhook feeds), using that store's filters. * **A subset of LookupAttributes:** the recorded events return in the CloudTrail record shape; the filter surface is the native log's, not CloudTrail's full attribute set.
A LookupEvents call is queried against the native audit log: Cloud Logging, the OCI Audit query, or the cluster's audit backend; the recorded events come back in the CloudTrail record shape, and the attribute-filter surface is a subset of LookupAttributes.
#### Data events & selectors CloudTrail's default trail records **management events**, the control-plane calls. Data events are the high-volume data-plane operations (S3 object reads and writes, Lambda invocations), configured with `PutEventSelectors`, as `event_selector` and `advanced_event_selector`. These map onto the native data-access log where the target has one, and the granularity is where they diverge. On **Google Cloud**, the selectors map onto **Data Access audit logs**, enabled per service and per type (`ADMIN_READ` / `DATA_READ` / `DATA_WRITE`) via `google_project_iam_audit_config`; this is *per-service-and-type* rather than CloudTrail's per-resource-ARN selectors, so common S3-object-style intent maps but the granularity differs. On **OCI**, data-plane object access (the Object Storage and Functions analog of S3 data events) rides **OCI Logging service logs**, which OCI keeps separate from the Audit management stream, so the selector maps onto service logs rather than the audit trail. On **Kubernetes**, the **audit policy itself** expresses data-access rules (verb, resource, and subresource at a chosen level); per-object S3- or Lambda-style data events have no direct Kubernetes analog, so this **undercovers** CloudTrail data events. * **Google Cloud.** Data Access audit logs, per service and type via `google_project_iam_audit_config`: per-service-and-type, not per-object-ARN. * **OCI.** OCI Logging service logs (Object Storage / function data-plane), kept separate from the Audit management stream. * **Kubernetes:** the audit policy's verb / resource / subresource rules; no per-object data-event analog, so this undercovers.
Data-event selectors map onto the native data-access log where the target has one: per-service-and-type Data Access logs on Google Cloud, OCI Logging service logs on OCI, and audit-policy rules on Kubernetes; the intent maps but the granularity differs.
#### Trail config & logging control The trail-config surface maps onto the native audit log. `CreateTrail` stands up nothing new: your `aws_cloudtrail` declaration maps onto the native log, because the cloud already audits itself, and `DescribeTrails`, `GetTrail`, and `ListTrails` report the mapped trail (name, home region, multi-region and organization flags). `UpdateTrail` accepts `is_multi_region_trail` and `is_organization_trail` changes; an AWS-only destination (an S3 bucket or an SNS topic) is **reported back rather than silently applied**. Logging control is where the always-on-versus-policy-gated distinction shows through. `GetTrailStatus` reports `IsLogging`: on Google Cloud and OCI it is continuously true; on Kubernetes it follows your audit policy. `StartLogging` returns success, because the always-on clouds are already recording, and on Kubernetes the log records per your policy. `StopLogging` is the call that diverges most: on **Google Cloud Audit Logs** and **OCI Audit** the platform audit log cannot be switched off, so a `StopLogging` that would blind your control-plane trail is **refused rather than silently dropping coverage**; on **Kubernetes** it maps to disabling the `kube-apiserver` audit policy, which stays the target cluster configuration to manage . * **CreateTrail maps onto the native log:** there is no separate cross-cloud trail to provision; `DescribeTrails` / `GetTrail` report the mapped trail. * **GetTrailStatus reports IsLogging:** continuously true on Google Cloud and OCI; per your audit policy on Kubernetes. * **StopLogging is refused on the always-on clouds.** Google Cloud Audit Logs and OCI Audit cannot be switched off; on Kubernetes it maps to managing the audit policy on the cluster.
The trail-config calls map onto the native audit log; logging control differs by whether the native log is always-on (refuse StopLogging) or policy-gated (StopLogging is your audit policy to manage).
#### Limitations The list below is the whole go/no-go picture for CloudTrail. Control-plane audit coverage is faithful: the native log records every management API call. The differences are the LookupEvents query surface, data-event granularity, StopLogging on the always-on clouds, CloudTrail Insights, log-file integrity, and the absence of a historical backlog. Every one is behavioral and named here rather than discovered later. △ Where CloudTrail and the target's native audit log diverge, read before you adopt * **The LookupEvents query surface is a subset:** a `LookupEvents` call is queried against the native audit log (Cloud Logging filters / the OCI Audit query / the cluster's audit backend), so you filter with the native log's query language rather than CloudTrail's full `LookupAttributes`, and the event body is the native audit entry mapped to a CloudTrail record. * **Data-event granularity differs.** CloudTrail's per-resource-ARN selectors map onto per-service-and-type Data Access audit logs on Google Cloud (`google_project_iam_audit_config`), OCI Logging service logs on OCI, and audit-policy verb/resource rules on Kubernetes; the common intent maps but the per-object granularity does not translate one-for-one, and on Kubernetes per-object data events have no direct analog. * **StopLogging is out of scope on the always-on clouds.** Google Cloud Audit Logs (Admin Activity) and OCI Audit cannot be turned off, so `StopLogging` is refused rather than silently dropping coverage. On Kubernetes it is Partial: it maps to disabling the `kube-apiserver` audit policy, which stays the target cluster configuration to manage. * **No CloudTrail Insights analog.** `PutInsightSelectors` / `GetInsightSelectors` anomaly detection has no native audit-log equivalent and is out of scope; use the target cloud's own log-based alerting over the native audit log. * **No digest-file integrity chain.** CloudTrail's `enable_log_file_validation` SHA-256 digest-file chain (and `ListPublicKeys`) is CloudTrail-specific; the native audit log has its own tamper-evidence: Cloud Logging's retention locks, OCI Audit's managed tamper-resistant retention, or whatever the Kubernetes audit backend's log store provides. * **No historical backlog migration:** the native audit log is already recording your control-plane activity on this cloud from before cutover; your existing AWS trail history stays in its S3 bucket on AWS, and new events are recorded to the native log going forward. Moving existing CloudTrail history is a separate export/import. #### Other considerations Beyond the query-surface and data-event boundaries above, a few facts shape how CloudTrail behaves as a declared edge: nothing runs at request time, the platform already audits itself, and coverage, retention, and cost are the native audit log's. * **Nothing is provisioned or called at runtime; the platform already audits itself:** unlike the request-time edges, the trail is recorded natively, so your `aws_cloudtrail` declaration maps onto the existing audit log rather than standing up a cross-cloud trail or a runtime API to call. * **Coverage is always-on on two clouds and policy-gated on the third.** Google Cloud Admin Activity and OCI Audit cannot be turned off (so `StopLogging` is refused); the Kubernetes API-server audit is recorded only while your audit policy is in effect, so on Kubernetes you own turning audit on and keeping it on. * **The native log holds the events, with its own retention and tamper-evidence:** history lives in Cloud Logging, the OCI Audit stream, or the Kubernetes audit backend, each with its own retention and integrity controls in place of CloudTrail's digest-file chain. * **Existing AWS trail history stays on AWS:** the native log records this cloud's activity from cutover forward; your prior CloudTrail history remains in its S3 bucket on AWS, and moving it is a separate export/import. * **Cost follows the native audit log:** management-event auditing is generally included (Admin Activity, OCI Audit), while data-access logging and the Kubernetes audit backend's log store bill under the target cloud's own model rather than a CloudTrail per-event charge. ## On Azure and Private Kubernetes | Operation | Area | Support | Depth | Notes | | ----------------------------------------- | --------------- | ------------ | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | GetEventSelectors | Data events | Partial | Most usage | returns the data-event selectors as mapped onto the Kubernetes API-server audit log's data-access configuration | | PutEventSelectors | Data events | Partial | Most usage | data-event selectors map to what the kube-apiserver audit policy can express (verb / resource / subresource rules); per-object S3 / Lambda-style data events have no direct Kubernetes analog, so this undercovers CloudTrail data events | | LookupEvents | History reads | Partial | Common | reads your control-plane event history from the cluster's audit backend (a log file, or the log store / SIEM the audit webhook feeds); the recorded events come back, but the attribute-filter surface is a subset of CloudTrail's LookupAttributes | | PutInsightSelectors / GetInsightSelectors | Insights | Out of scope | Full surface | CloudTrail Insights anomaly detection has no native audit-log analog; use the target cloud's own log-based alerting | | ListPublicKeys (log-file validation) | Integrity | Out of scope | Full surface | Kubernetes has no CloudTrail-style SHA-256 digest-file chain; integrity is whatever the downstream log store provides. | | StartLogging | Logging control | Partial | Most usage | returns success; the Kubernetes API-server audit log records per the target cluster's audit policy | | StopLogging | Logging control | Partial | Most usage | StopLogging maps to disabling the kube-apiserver audit policy, but Tensor9 does not turn your audit policy off for you; manage the policy on the cluster | | CreateTrail | Trail config | Supported | Common | the aws\_cloudtrail declaration maps onto the Kubernetes API-server audit log; there is no separate cross-cloud trail to stand up because the cloud already audits itself | | DescribeTrails | Trail config | Supported | Common | returns the trail that maps onto the Kubernetes API-server audit log | | GetTrail | Trail config | Supported | Common | reads the mapped trail definition: name, home region, multi-region and organization flags | | GetTrailStatus | Trail config | Partial | Most usage | reports IsLogging per your audit policy: the Kubernetes API-server audit log records whenever the policy is in effect; the timestamps are the native log's, not a per-trail S3 delivery | | ListTrails | Trail config | Supported | Full surface | lists the trails that map onto the Kubernetes API-server audit log | | UpdateTrail | Trail config | Partial | Most usage | name / is\_multi\_region\_trail / is\_organization\_trail changes are accepted; an AWS-only destination (an S3 bucket / SNS topic) is reported back rather than silently applied | #### How it works On AWS, CloudTrail records your **control-plane audit trail**: who called which API, when, and from where. You do not call a "CloudTrail API" at runtime to make that happen; the platform records it for you. That is the key difference from the request-time edges: there is no runtime call from your application to log. Every cloud already produces the same kind of trail natively, so your `aws_cloudtrail` declaration **maps onto the target's own native audit log** rather than provisioning a separate cross-cloud trail, because each cloud audits itself. The native log is recorded by the platform: on Google Cloud Audit Logs and **OCI Audit** it is genuinely always on and cannot be disabled; on **Kubernetes** the API-server audit is recorded *whenever your audit policy is in effect*, a cluster configuration that is not on by default. Reading history with `LookupEvents` queries that native log and returns the recorded events in the CloudTrail response shape. * **Nothing to provision:** your `aws_cloudtrail` declaration maps onto the target's native audit log; there is no separate cross-cloud trail to stand up. * **Recorded by the platform:** the native audit log records every control-plane API call: always on Google Cloud Audit Logs and OCI Audit, recorded whenever your audit policy is in effect on Kubernetes. * **History reads come off the native log.** `LookupEvents` queries the native audit log and returns the recorded events; no runtime CloudTrail call in your application makes the trail happen.
Your aws\_cloudtrail declaration maps onto the target's native audit log; there is no separate cross-cloud trail to provision, because each cloud audits itself; LookupEvents reads history from that native log.
#### The native audit log Each cloud's native audit log is its own platform service, so the always-on-versus-policy-gated distinction is real rather than cosmetic. On **Google Cloud**, the trail maps onto **Cloud Audit Logs**. Admin Activity audit logs are always on and cannot be disabled; **Data Access** audit logs are opt-in per service and per type (`ADMIN_READ` / `DATA_READ` / `DATA_WRITE`) via `google_project_iam_audit_config`. Entries land in Cloud Logging under the `cloudaudit.googleapis.com` log names. On **OCI**, the trail maps onto OCI Audit , which is **always on for every tenancy** and records every API call automatically; `oci_audit_configuration` controls only the retention period, not whether auditing runs. On **Kubernetes**, the trail maps onto the **API-server audit policy and its backend**: a `kube-apiserver` audit policy (a cluster configuration, *not on by default*) decides which requests are recorded and at what level (`Metadata` / `Request` / `RequestResponse`), and an audit backend (a log file, or a webhook feeding a log store or SIEM) receives them. It is recorded **whenever your audit policy is in effect**. * **Google Cloud Audit Logs.** Admin Activity is always-on and cannot be disabled; Data Access is opt-in per service and type via `google_project_iam_audit_config`. * **OCI Audit:** always on for the tenancy, recording every API call; `oci_audit_configuration` sets only the retention period. * **Kubernetes API-server audit:** policy-gated: the `kube-apiserver` audit policy plus an audit backend, not on by default; recorded whenever your policy is in effect.
Each target's native audit log is its own platform service: always-on on Google Cloud and OCI, policy-gated on Kubernetes; your trail maps onto it.
#### Reading history (LookupEvents) `LookupEvents` is CloudTrail's history read: query the recent window of control-plane events, filtered by **LookupAttributes** such as `EventName`, `Username`, or `ResourceType`. Because the events are already recorded in the native audit log, a `LookupEvents` call maps onto a **query against that log**, and the recorded events are returned in the CloudTrail record shape. The query surface is the native log's. On **Google Cloud** the read runs against Cloud Logging (the Logs Explorer or the Logging API), filtering on `resource.type` and `protoPayload.methodName` under the `cloudaudit.googleapis.com` log names. On **OCI** it runs against the **OCI Audit query** (or Logging Analytics), filtering on event source and compartment. On **Kubernetes** it runs against the cluster's audit backend (the log store or SIEM the audit webhook feeds) using that store's filters. In every case the recorded events come back, but the attribute-filter surface is a subset of CloudTrail's LookupAttributes : you filter with what the native log's query language expresses, and the event body is the native audit entry mapped to a CloudTrail record. * **Google Cloud.** Cloud Logging, filtering on `resource.type` / `protoPayload.methodName` under `cloudaudit.googleapis.com`. * **OCI:** the OCI Audit query (or Logging Analytics), filtering on event source and compartment. * **Kubernetes:** the cluster's audit backend (the log store / SIEM the audit webhook feeds), using that store's filters. * **A subset of LookupAttributes:** the recorded events return in the CloudTrail record shape; the filter surface is the native log's, not CloudTrail's full attribute set.
A LookupEvents call is queried against the native audit log: Cloud Logging, the OCI Audit query, or the cluster's audit backend; the recorded events come back in the CloudTrail record shape, and the attribute-filter surface is a subset of LookupAttributes.
#### Data events & selectors CloudTrail's default trail records **management events**, the control-plane calls. Data events are the high-volume data-plane operations (S3 object reads and writes, Lambda invocations), configured with `PutEventSelectors`, as `event_selector` and `advanced_event_selector`. These map onto the native data-access log where the target has one, and the granularity is where they diverge. On **Google Cloud**, the selectors map onto **Data Access audit logs**, enabled per service and per type (`ADMIN_READ` / `DATA_READ` / `DATA_WRITE`) via `google_project_iam_audit_config`; this is *per-service-and-type* rather than CloudTrail's per-resource-ARN selectors, so common S3-object-style intent maps but the granularity differs. On **OCI**, data-plane object access (the Object Storage and Functions analog of S3 data events) rides **OCI Logging service logs**, which OCI keeps separate from the Audit management stream, so the selector maps onto service logs rather than the audit trail. On **Kubernetes**, the **audit policy itself** expresses data-access rules (verb, resource, and subresource at a chosen level); per-object S3- or Lambda-style data events have no direct Kubernetes analog, so this **undercovers** CloudTrail data events. * **Google Cloud.** Data Access audit logs, per service and type via `google_project_iam_audit_config`: per-service-and-type, not per-object-ARN. * **OCI.** OCI Logging service logs (Object Storage / function data-plane), kept separate from the Audit management stream. * **Kubernetes:** the audit policy's verb / resource / subresource rules; no per-object data-event analog, so this undercovers.
Data-event selectors map onto the native data-access log where the target has one: per-service-and-type Data Access logs on Google Cloud, OCI Logging service logs on OCI, and audit-policy rules on Kubernetes; the intent maps but the granularity differs.
#### Trail config & logging control The trail-config surface maps onto the native audit log. `CreateTrail` stands up nothing new: your `aws_cloudtrail` declaration maps onto the native log, because the cloud already audits itself, and `DescribeTrails`, `GetTrail`, and `ListTrails` report the mapped trail (name, home region, multi-region and organization flags). `UpdateTrail` accepts `is_multi_region_trail` and `is_organization_trail` changes; an AWS-only destination (an S3 bucket or an SNS topic) is **reported back rather than silently applied**. Logging control is where the always-on-versus-policy-gated distinction shows through. `GetTrailStatus` reports `IsLogging`: on Google Cloud and OCI it is continuously true; on Kubernetes it follows your audit policy. `StartLogging` returns success, because the always-on clouds are already recording, and on Kubernetes the log records per your policy. `StopLogging` is the call that diverges most: on **Google Cloud Audit Logs** and **OCI Audit** the platform audit log cannot be switched off, so a `StopLogging` that would blind your control-plane trail is **refused rather than silently dropping coverage**; on **Kubernetes** it maps to disabling the `kube-apiserver` audit policy, which stays the target cluster configuration to manage . * **CreateTrail maps onto the native log:** there is no separate cross-cloud trail to provision; `DescribeTrails` / `GetTrail` report the mapped trail. * **GetTrailStatus reports IsLogging:** continuously true on Google Cloud and OCI; per your audit policy on Kubernetes. * **StopLogging is refused on the always-on clouds.** Google Cloud Audit Logs and OCI Audit cannot be switched off; on Kubernetes it maps to managing the audit policy on the cluster.
The trail-config calls map onto the native audit log; logging control differs by whether the native log is always-on (refuse StopLogging) or policy-gated (StopLogging is your audit policy to manage).
#### Limitations The list below is the whole go/no-go picture for CloudTrail. Control-plane audit coverage is faithful: the native log records every management API call. The differences are the LookupEvents query surface, data-event granularity, StopLogging on the always-on clouds, CloudTrail Insights, log-file integrity, and the absence of a historical backlog. Every one is behavioral and named here rather than discovered later. △ Where CloudTrail and the target's native audit log diverge, read before you adopt * **The LookupEvents query surface is a subset:** a `LookupEvents` call is queried against the native audit log (Cloud Logging filters / the OCI Audit query / the cluster's audit backend), so you filter with the native log's query language rather than CloudTrail's full `LookupAttributes`, and the event body is the native audit entry mapped to a CloudTrail record. * **Data-event granularity differs.** CloudTrail's per-resource-ARN selectors map onto per-service-and-type Data Access audit logs on Google Cloud (`google_project_iam_audit_config`), OCI Logging service logs on OCI, and audit-policy verb/resource rules on Kubernetes; the common intent maps but the per-object granularity does not translate one-for-one, and on Kubernetes per-object data events have no direct analog. * **StopLogging is out of scope on the always-on clouds.** Google Cloud Audit Logs (Admin Activity) and OCI Audit cannot be turned off, so `StopLogging` is refused rather than silently dropping coverage. On Kubernetes it is Partial: it maps to disabling the `kube-apiserver` audit policy, which stays the target cluster configuration to manage. * **No CloudTrail Insights analog.** `PutInsightSelectors` / `GetInsightSelectors` anomaly detection has no native audit-log equivalent and is out of scope; use the target cloud's own log-based alerting over the native audit log. * **No digest-file integrity chain.** CloudTrail's `enable_log_file_validation` SHA-256 digest-file chain (and `ListPublicKeys`) is CloudTrail-specific; the native audit log has its own tamper-evidence: Cloud Logging's retention locks, OCI Audit's managed tamper-resistant retention, or whatever the Kubernetes audit backend's log store provides. * **No historical backlog migration:** the native audit log is already recording your control-plane activity on this cloud from before cutover; your existing AWS trail history stays in its S3 bucket on AWS, and new events are recorded to the native log going forward. Moving existing CloudTrail history is a separate export/import. #### Other considerations Beyond the query-surface and data-event boundaries above, a few facts shape how CloudTrail behaves as a declared edge: nothing runs at request time, the platform already audits itself, and coverage, retention, and cost are the native audit log's. * **Nothing is provisioned or called at runtime; the platform already audits itself:** unlike the request-time edges, the trail is recorded natively, so your `aws_cloudtrail` declaration maps onto the existing audit log rather than standing up a cross-cloud trail or a runtime API to call. * **Coverage is always-on on two clouds and policy-gated on the third.** Google Cloud Admin Activity and OCI Audit cannot be turned off (so `StopLogging` is refused); the Kubernetes API-server audit is recorded only while your audit policy is in effect, so on Kubernetes you own turning audit on and keeping it on. * **The native log holds the events, with its own retention and tamper-evidence:** history lives in Cloud Logging, the OCI Audit stream, or the Kubernetes audit backend, each with its own retention and integrity controls in place of CloudTrail's digest-file chain. * **Existing AWS trail history stays on AWS:** the native log records this cloud's activity from cutover forward; your prior CloudTrail history remains in its S3 bucket on AWS, and moving it is a separate export/import. * **Cost follows the native audit log:** management-event auditing is generally included (Admin Activity, OCI Audit), while data-access logging and the Kubernetes audit backend's log store bill under the target cloud's own model rather than a CloudTrail per-event charge. ## On OCI | Operation | Area | Support | Depth | Notes | | ----------------------------------------- | --------------- | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | GetEventSelectors | Data events | Partial | Most usage | returns the data-event selectors as mapped onto OCI Audit's data-access configuration | | PutEventSelectors | Data events | Partial | Most usage | data-event selectors map onto OCI Logging service logs (Object Storage / function data-plane access), which OCI keeps separate from the Audit management stream; the intent maps but the source is service logs rather than the audit trail | | LookupEvents | History reads | Partial | Common | reads your control-plane event history from the OCI Audit service (the Audit query / Logging Analytics); the recorded events come back, but the attribute-filter surface is a subset of CloudTrail's LookupAttributes | | PutInsightSelectors / GetInsightSelectors | Insights | Out of scope | Full surface | CloudTrail Insights anomaly detection has no native audit-log analog; use the target cloud's own log-based alerting | | ListPublicKeys (log-file validation) | Integrity | Out of scope | Full surface | OCI Audit has no CloudTrail-style digest-file chain; integrity rests on the Audit service's managed, tamper-resistant retention. | | StartLogging | Logging control | Partial | Most usage | returns success: OCI Audit is always recording, so there is nothing to switch on | | StopLogging | Logging control | Out of scope | Most usage | the platform audit log cannot be switched off; a StopLogging that would blind your control-plane audit trail is refused rather than silently dropping coverage | | CreateTrail | Trail config | Supported | Common | the aws\_cloudtrail declaration maps onto OCI Audit; there is no separate cross-cloud trail to stand up because the cloud already audits itself | | DescribeTrails | Trail config | Supported | Common | returns the trail that maps onto OCI Audit | | GetTrail | Trail config | Supported | Common | reads the mapped trail definition: name, home region, multi-region and organization flags | | GetTrailStatus | Trail config | Partial | Most usage | reports IsLogging=true because OCI Audit records continuously; the timestamps are the native log's, not a per-trail S3 delivery | | ListTrails | Trail config | Supported | Full surface | lists the trails that map onto OCI Audit | | UpdateTrail | Trail config | Partial | Most usage | name / is\_multi\_region\_trail / is\_organization\_trail changes are accepted; an AWS-only destination (an S3 bucket / SNS topic) is reported back rather than silently applied | #### How it works On AWS, CloudTrail records your **control-plane audit trail**: who called which API, when, and from where. You do not call a "CloudTrail API" at runtime to make that happen; the platform records it for you. That is the key difference from the request-time edges: there is no runtime call from your application to log. Every cloud already produces the same kind of trail natively, so your `aws_cloudtrail` declaration **maps onto the target's own native audit log** rather than provisioning a separate cross-cloud trail, because each cloud audits itself. The native log is recorded by the platform: on Google Cloud Audit Logs and **OCI Audit** it is genuinely always on and cannot be disabled; on **Kubernetes** the API-server audit is recorded *whenever your audit policy is in effect*, a cluster configuration that is not on by default. Reading history with `LookupEvents` queries that native log and returns the recorded events in the CloudTrail response shape. * **Nothing to provision:** your `aws_cloudtrail` declaration maps onto the target's native audit log; there is no separate cross-cloud trail to stand up. * **Recorded by the platform:** the native audit log records every control-plane API call: always on Google Cloud Audit Logs and OCI Audit, recorded whenever your audit policy is in effect on Kubernetes. * **History reads come off the native log.** `LookupEvents` queries the native audit log and returns the recorded events; no runtime CloudTrail call in your application makes the trail happen.
Your aws\_cloudtrail declaration maps onto the target's native audit log; there is no separate cross-cloud trail to provision, because each cloud audits itself; LookupEvents reads history from that native log.
#### The native audit log Each cloud's native audit log is its own platform service, so the always-on-versus-policy-gated distinction is real rather than cosmetic. On **Google Cloud**, the trail maps onto **Cloud Audit Logs**. Admin Activity audit logs are always on and cannot be disabled; **Data Access** audit logs are opt-in per service and per type (`ADMIN_READ` / `DATA_READ` / `DATA_WRITE`) via `google_project_iam_audit_config`. Entries land in Cloud Logging under the `cloudaudit.googleapis.com` log names. On **OCI**, the trail maps onto OCI Audit , which is **always on for every tenancy** and records every API call automatically; `oci_audit_configuration` controls only the retention period, not whether auditing runs. On **Kubernetes**, the trail maps onto the **API-server audit policy and its backend**: a `kube-apiserver` audit policy (a cluster configuration, *not on by default*) decides which requests are recorded and at what level (`Metadata` / `Request` / `RequestResponse`), and an audit backend (a log file, or a webhook feeding a log store or SIEM) receives them. It is recorded **whenever your audit policy is in effect**. * **Google Cloud Audit Logs.** Admin Activity is always-on and cannot be disabled; Data Access is opt-in per service and type via `google_project_iam_audit_config`. * **OCI Audit:** always on for the tenancy, recording every API call; `oci_audit_configuration` sets only the retention period. * **Kubernetes API-server audit:** policy-gated: the `kube-apiserver` audit policy plus an audit backend, not on by default; recorded whenever your policy is in effect.
Each target's native audit log is its own platform service: always-on on Google Cloud and OCI, policy-gated on Kubernetes; your trail maps onto it.
#### Reading history (LookupEvents) `LookupEvents` is CloudTrail's history read: query the recent window of control-plane events, filtered by **LookupAttributes** such as `EventName`, `Username`, or `ResourceType`. Because the events are already recorded in the native audit log, a `LookupEvents` call maps onto a **query against that log**, and the recorded events are returned in the CloudTrail record shape. The query surface is the native log's. On **Google Cloud** the read runs against Cloud Logging (the Logs Explorer or the Logging API), filtering on `resource.type` and `protoPayload.methodName` under the `cloudaudit.googleapis.com` log names. On **OCI** it runs against the **OCI Audit query** (or Logging Analytics), filtering on event source and compartment. On **Kubernetes** it runs against the cluster's audit backend (the log store or SIEM the audit webhook feeds) using that store's filters. In every case the recorded events come back, but the attribute-filter surface is a subset of CloudTrail's LookupAttributes : you filter with what the native log's query language expresses, and the event body is the native audit entry mapped to a CloudTrail record. * **Google Cloud.** Cloud Logging, filtering on `resource.type` / `protoPayload.methodName` under `cloudaudit.googleapis.com`. * **OCI:** the OCI Audit query (or Logging Analytics), filtering on event source and compartment. * **Kubernetes:** the cluster's audit backend (the log store / SIEM the audit webhook feeds), using that store's filters. * **A subset of LookupAttributes:** the recorded events return in the CloudTrail record shape; the filter surface is the native log's, not CloudTrail's full attribute set.
A LookupEvents call is queried against the native audit log: Cloud Logging, the OCI Audit query, or the cluster's audit backend; the recorded events come back in the CloudTrail record shape, and the attribute-filter surface is a subset of LookupAttributes.
#### Data events & selectors CloudTrail's default trail records **management events**, the control-plane calls. Data events are the high-volume data-plane operations (S3 object reads and writes, Lambda invocations), configured with `PutEventSelectors`, as `event_selector` and `advanced_event_selector`. These map onto the native data-access log where the target has one, and the granularity is where they diverge. On **Google Cloud**, the selectors map onto **Data Access audit logs**, enabled per service and per type (`ADMIN_READ` / `DATA_READ` / `DATA_WRITE`) via `google_project_iam_audit_config`; this is *per-service-and-type* rather than CloudTrail's per-resource-ARN selectors, so common S3-object-style intent maps but the granularity differs. On **OCI**, data-plane object access (the Object Storage and Functions analog of S3 data events) rides **OCI Logging service logs**, which OCI keeps separate from the Audit management stream, so the selector maps onto service logs rather than the audit trail. On **Kubernetes**, the **audit policy itself** expresses data-access rules (verb, resource, and subresource at a chosen level); per-object S3- or Lambda-style data events have no direct Kubernetes analog, so this **undercovers** CloudTrail data events. * **Google Cloud.** Data Access audit logs, per service and type via `google_project_iam_audit_config`: per-service-and-type, not per-object-ARN. * **OCI.** OCI Logging service logs (Object Storage / function data-plane), kept separate from the Audit management stream. * **Kubernetes:** the audit policy's verb / resource / subresource rules; no per-object data-event analog, so this undercovers.
Data-event selectors map onto the native data-access log where the target has one: per-service-and-type Data Access logs on Google Cloud, OCI Logging service logs on OCI, and audit-policy rules on Kubernetes; the intent maps but the granularity differs.
#### Trail config & logging control The trail-config surface maps onto the native audit log. `CreateTrail` stands up nothing new: your `aws_cloudtrail` declaration maps onto the native log, because the cloud already audits itself, and `DescribeTrails`, `GetTrail`, and `ListTrails` report the mapped trail (name, home region, multi-region and organization flags). `UpdateTrail` accepts `is_multi_region_trail` and `is_organization_trail` changes; an AWS-only destination (an S3 bucket or an SNS topic) is **reported back rather than silently applied**. Logging control is where the always-on-versus-policy-gated distinction shows through. `GetTrailStatus` reports `IsLogging`: on Google Cloud and OCI it is continuously true; on Kubernetes it follows your audit policy. `StartLogging` returns success, because the always-on clouds are already recording, and on Kubernetes the log records per your policy. `StopLogging` is the call that diverges most: on **Google Cloud Audit Logs** and **OCI Audit** the platform audit log cannot be switched off, so a `StopLogging` that would blind your control-plane trail is **refused rather than silently dropping coverage**; on **Kubernetes** it maps to disabling the `kube-apiserver` audit policy, which stays the target cluster configuration to manage . * **CreateTrail maps onto the native log:** there is no separate cross-cloud trail to provision; `DescribeTrails` / `GetTrail` report the mapped trail. * **GetTrailStatus reports IsLogging:** continuously true on Google Cloud and OCI; per your audit policy on Kubernetes. * **StopLogging is refused on the always-on clouds.** Google Cloud Audit Logs and OCI Audit cannot be switched off; on Kubernetes it maps to managing the audit policy on the cluster.
The trail-config calls map onto the native audit log; logging control differs by whether the native log is always-on (refuse StopLogging) or policy-gated (StopLogging is your audit policy to manage).
#### Limitations The list below is the whole go/no-go picture for CloudTrail. Control-plane audit coverage is faithful: the native log records every management API call. The differences are the LookupEvents query surface, data-event granularity, StopLogging on the always-on clouds, CloudTrail Insights, log-file integrity, and the absence of a historical backlog. Every one is behavioral and named here rather than discovered later. △ Where CloudTrail and the target's native audit log diverge, read before you adopt * **The LookupEvents query surface is a subset:** a `LookupEvents` call is queried against the native audit log (Cloud Logging filters / the OCI Audit query / the cluster's audit backend), so you filter with the native log's query language rather than CloudTrail's full `LookupAttributes`, and the event body is the native audit entry mapped to a CloudTrail record. * **Data-event granularity differs.** CloudTrail's per-resource-ARN selectors map onto per-service-and-type Data Access audit logs on Google Cloud (`google_project_iam_audit_config`), OCI Logging service logs on OCI, and audit-policy verb/resource rules on Kubernetes; the common intent maps but the per-object granularity does not translate one-for-one, and on Kubernetes per-object data events have no direct analog. * **StopLogging is out of scope on the always-on clouds.** Google Cloud Audit Logs (Admin Activity) and OCI Audit cannot be turned off, so `StopLogging` is refused rather than silently dropping coverage. On Kubernetes it is Partial: it maps to disabling the `kube-apiserver` audit policy, which stays the target cluster configuration to manage. * **No CloudTrail Insights analog.** `PutInsightSelectors` / `GetInsightSelectors` anomaly detection has no native audit-log equivalent and is out of scope; use the target cloud's own log-based alerting over the native audit log. * **No digest-file integrity chain.** CloudTrail's `enable_log_file_validation` SHA-256 digest-file chain (and `ListPublicKeys`) is CloudTrail-specific; the native audit log has its own tamper-evidence: Cloud Logging's retention locks, OCI Audit's managed tamper-resistant retention, or whatever the Kubernetes audit backend's log store provides. * **No historical backlog migration:** the native audit log is already recording your control-plane activity on this cloud from before cutover; your existing AWS trail history stays in its S3 bucket on AWS, and new events are recorded to the native log going forward. Moving existing CloudTrail history is a separate export/import. #### Other considerations Beyond the query-surface and data-event boundaries above, a few facts shape how CloudTrail behaves as a declared edge: nothing runs at request time, the platform already audits itself, and coverage, retention, and cost are the native audit log's. * **Nothing is provisioned or called at runtime; the platform already audits itself:** unlike the request-time edges, the trail is recorded natively, so your `aws_cloudtrail` declaration maps onto the existing audit log rather than standing up a cross-cloud trail or a runtime API to call. * **Coverage is always-on on two clouds and policy-gated on the third.** Google Cloud Admin Activity and OCI Audit cannot be turned off (so `StopLogging` is refused); the Kubernetes API-server audit is recorded only while your audit policy is in effect, so on Kubernetes you own turning audit on and keeping it on. * **The native log holds the events, with its own retention and tamper-evidence:** history lives in Cloud Logging, the OCI Audit stream, or the Kubernetes audit backend, each with its own retention and integrity controls in place of CloudTrail's digest-file chain. * **Existing AWS trail history stays on AWS:** the native log records this cloud's activity from cutover forward; your prior CloudTrail history remains in its S3 bucket on AWS, and moving it is a separate export/import. * **Cost follows the native audit log:** management-event auditing is generally included (Admin Activity, OCI Audit), while data-access logging and the Kubernetes audit backend's log store bill under the target cloud's own model rather than a CloudTrail per-event charge. [Service Catalog](/service-adapters/catalog).