Normal Feature Overview
In ACS 4.6 there is a Tech Preview of kubernetes security policies which ACS uses as a gitops solution to populate their database of policies. We should add this new kind of policy to what we can discover.
Goals
Use Cases
Questions to answer
Requirements
| Requirement | Notes | isMvp? |
|---|---|---|
| CI - MUST be running successfully with test automation | This is a requirement for ALL features. |
YES |
| Release Technical Enablement | Provide necessary release enablement details and documents. |
YES |
Out of Scope
- ...
Background, and strategic fit
This Section: What does the person writing code, testing, documenting
need to know? What context can be provided to frame this feature?
Assumptions
- ...
Customer Considerations
- ...
Documentation Considerations
Questions to be addressed:
- What educational or reference material (docs) is required to support this
product feature? For users/admins? Other functions (security officers, etc)? - Does this feature have a doc impact?
- New Content, Updates to existing content, Release Note, or No Doc Impact
- If unsure and no Technical Writer is available, please contact Content
Strategy. - What concepts do customers need to understand to be successful in
[action]? - How do we expect customers will use the feature? For what purpose(s)?
- What reference material might a customer want/need to complete [action]?
- Is there source material that can be used as reference for the Technical
Writer in writing the content? If yes, please link if available. - What is the doc impact (New Content, Updates to existing content, or
Release Note)?
Why is this important?
ACS policies are an important part of workload security. We should discover their policies. Consider whether we can use the ACS APIs to go deeper to provide:
- Related resources
- Policy Status
- Etc... linking to the ACS console for example
Scenarios
Here's a sample CR that should be discoverable with Search. Note this is currently Tech Preview and final implementation for GA may be different. We can follow up with ACS to learn what changes may be coming.
apiVersion: config.stackrox.io/v1alpha1
kind: SecurityPolicy
metadata:
creationTimestamp: "2024-12-04T18:42:34Z"
finalizers:
- securitypolicies.config.stackrox.io/finalizer
generation: 2
name: kubernetes-actions-exec-into-pod-copy
namespace: rhacs-operator
resourceVersion: "1152860"
uid: 32286e5a-e336-41a0-8070-5d26786a8e55
spec:
categories:
- Kubernetes Events
description: Alerts when Kubernetes API receives request to execute command in container
enforcementActions:
- FAIL_KUBE_REQUEST_ENFORCEMENT
- KILL_POD_ENFORCEMENT
eventSource: DEPLOYMENT_EVENT
exclusions:
- deployment:
name: thanos-querier
scope:
label: {}
namespace: openshift-monitoring
image: {}
- deployment:
name: prometheus-k8s
scope:
label: {}
namespace: openshift-monitoring
image: {}
- deployment:
name: ovnkube-node
scope:
label: {}
namespace: openshift-ovn-kubernetes
image: {}
- deployment:
name: etcd-ci-ln-.*-master-\d+
scope:
label: {}
namespace: openshift-etcd
image: {}
- deployment:
scope:
label: {}
namespace: openshift*
image: {}
lifecycleStages:
- RUNTIME
mitreAttackVectors:
- tactic: TA0002
techniques:
- T1609
- tactic: TA0002
techniques:
- T1059.004
policyName: 'Kubernetes Actions: Exec into Pod (COPY)'
policySections:
- policyGroups:
- booleanOperator: OR
fieldName: Kubernetes Resource
values:
- value: PODS_EXEC
rationale: '''pods/exec'' is non-standard approach for interacting with containers.
Attackers with permissions could execute malicious code and compromise resources
within a cluster'
remediation: Restrict RBAC access to the 'pods/exec' resource according to the Principle
of Least Privilege. Limit such usage only to development, testing or debugging
(non-production) activities
severity: MEDIUM_SEVERITY
status:
accepted: true
message: Successfully updated policy
policyId: 64dd531b-2ef1-4a29-b33a-55e5e03b6fc0
The status indicates this Policy was successfully ingested into the ACS database. Further details would require using their API.