You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
As an AKS Administrator, I want to see RequestResponse level audit logs of custom resources in the AKSAuditAdmin Log Analytics table. Currently, the built-in Kubernetes objects have this level of logs, but other resources (eg. ArgoCD Application objects) only have Metadata level logs. This makes many high-level objects hard if not impossible to properly audit.
Describe the solution you'd like
I want to be able to configure the API server's audit logging policy, so that I can get RequestResponse level logs about my custom resources. I think for this, I only need a portion of the logging Policy configuration exposed, specifically, the rules list of the audit.k8s.io/v1/Policy object.
Technical suggestion
My insight about this exposure is that there are already similar configurations exposed. For example, on the AKS (nodepool) object, there is an agentpoolProfiles[].kubeletConfig object, which enables configuring parameters of the kubelet. I think, this is essentialy the same approach as what we need: The exposure of configuration options of a component that is otherwise managed by Azure.
So, my suggestion is to do something similar for the API server. Let's say, there'd be an apiServerConfigobject on the AKS resource, at first only containing the object which is relevant for my request: auditLogPolicyExtraRules[] which would let me provide the list of rules additional to what AKS currently has.
Describe alternatives you've considered
I haven't found any satisfying alternative. In a specific case, I was able to correlate the CRD Metadata logs with a RequestResponse Deployment log based on their time and the change in the Deployment, but this approach does not always work.
Additional context
I have discussed this issue with a Microsoft Support Engineer in support ticket 2501090050001193. Also, the problem this issue requests to solve is the same as for #2684, #3919, #2145 and #1873.
The text was updated successfully, but these errors were encountered:
@ecklm - sorry for delayed response. I will take this feature request with our team and get back to you on either timeline for it or more info if any existing mechanism can help with it.
Is your feature request related to a problem? Please describe.
As an AKS Administrator, I want to see RequestResponse level audit logs of custom resources in the AKSAuditAdmin Log Analytics table. Currently, the built-in Kubernetes objects have this level of logs, but other resources (eg. ArgoCD Application objects) only have Metadata level logs. This makes many high-level objects hard if not impossible to properly audit.
Describe the solution you'd like
I want to be able to configure the API server's audit logging policy, so that I can get RequestResponse level logs about my custom resources. I think for this, I only need a portion of the logging Policy configuration exposed, specifically, the rules list of the audit.k8s.io/v1/Policy object.
Technical suggestion
My insight about this exposure is that there are already similar configurations exposed. For example, on the AKS (nodepool) object, there is an
agentpoolProfiles[].kubeletConfig
object, which enables configuring parameters of the kubelet. I think, this is essentialy the same approach as what we need: The exposure of configuration options of a component that is otherwise managed by Azure.So, my suggestion is to do something similar for the API server. Let's say, there'd be an
apiServerConfigobject
on the AKS resource, at first only containing the object which is relevant for my request:auditLogPolicyExtraRules[]
which would let me provide the list of rules additional to what AKS currently has.Describe alternatives you've considered
I haven't found any satisfying alternative. In a specific case, I was able to correlate the CRD Metadata logs with a RequestResponse Deployment log based on their time and the change in the Deployment, but this approach does not always work.
Additional context
I have discussed this issue with a Microsoft Support Engineer in support ticket 2501090050001193. Also, the problem this issue requests to solve is the same as for #2684, #3919, #2145 and #1873.
The text was updated successfully, but these errors were encountered: