CIS Version : 2.17.0
Build: f5networks/k8s-bigip-ctlr:latest
BIGIP Version: Big IP 17.1.1.3
AS3 Version: 3.50.1
Agent Mode: AS3
Orchestration: Tanzu
Orchestration Version: v1.27.11+vmware.1-fips.1
Pool Mode: nodeportlocal
Additional Setup details: Tanzu / Antrea CNI
Description
We are using CIS with CRDs in Tanzu with nodeportlocal mode. We see that CIS is regularly modifying data groups starting with "____appsvcs" even there are no changes to the published applications.
This causes alarms for us because unplanned changes are made to the BIG-IP.
It looks like CIS is reposting the declaration because of re-ordering of the pool-members.
In the configuration are different different ports for the poolMembers, that's how NodePortLocal works. It opens a port for each pod running on the worker node. As long as there is no change to the deployment/pods there shouldn't be a change in this mapping.
Steps To Reproduce
1) leave the deplmoyents as they are
2) wait some time (sometimes days)
3) check audit logs or data-groups for changes
Expected Result
As long as there are no configuration changes, no new declaration should be posted.
Actual Result
There are configuration changes to the bigip because the data-groups are adjusted.
Setup Details
CIS Version : 2.17.0 Build: f5networks/k8s-bigip-ctlr:latest BIGIP Version: Big IP 17.1.1.3 AS3 Version: 3.50.1 Agent Mode: AS3 Orchestration: Tanzu Orchestration Version: v1.27.11+vmware.1-fips.1 Pool Mode: nodeportlocal Additional Setup details: Tanzu / Antrea CNI
Description
We are using CIS with CRDs in Tanzu with nodeportlocal mode. We see that CIS is regularly modifying data groups starting with "____appsvcs" even there are no changes to the published applications. This causes alarms for us because unplanned changes are made to the BIG-IP. It looks like CIS is reposting the declaration because of re-ordering of the pool-members. In the configuration are different different ports for the poolMembers, that's how NodePortLocal works. It opens a port for each pod running on the worker node. As long as there is no change to the deployment/pods there shouldn't be a change in this mapping.
Steps To Reproduce
1) leave the deplmoyents as they are 2) wait some time (sometimes days) 3) check audit logs or data-groups for changes
Expected Result
As long as there are no configuration changes, no new declaration should be posted.
Actual Result
There are configuration changes to the bigip because the data-groups are adjusted.
Diagnostic Information
declaration versions from the bigip as3_declarations.zip