Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow attaching to pods in kube integration tests #40971

Merged
merged 1 commit into from
Apr 27, 2024
Merged

allow attaching to pods in kube integration tests #40971

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions fixtures/ci-teleport-rbac/ci-teleport.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@
rules:
- apiGroups: [""]
resources: ["users", "groups"]
verbs: ["impersonate"]

Check warning on line 16 in fixtures/ci-teleport-rbac/ci-teleport.yaml

View check run for this annotation

Orca Security (US) / Orca Security - Infrastructure as Code

[LOW] Controller of pods with impersonation privileges service account 

Details:
Roles or ClusterRoles with the permission 'impersonate' allow subjects to assume
the rights of other users, groups, or service accounts. In case of compromise,
attackers may abuse this sudo-like functionality to achieve privilege escalation

Recommendation:
metadata.name={{ci-teleport}}.rules[0].verbs should not include the 'impersonate'
verb
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["create"]
Expand All @@ -23,11 +23,11 @@
kind: Role
metadata:
name: ci-teleport-sa
namespace: teletest

Check warning on line 26 in fixtures/ci-teleport-rbac/ci-teleport.yaml

View check run for this annotation

Orca Security (US) / Orca Security - Infrastructure as Code

[INFO] Ensure Administrative Boundaries Between Resources 

Details:
As a best practice, ensure that is made the correct use of namespaces to
adequately administer your resources. Kubernetes Authorization plugins can also
be used to create policies that segregate user access to namespaces.

Recommendation:
ensure that these namespaces are the ones you need and are adequately
administered as per your requirements.
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["create"]

Check failure on line 30 in fixtures/ci-teleport-rbac/ci-teleport.yaml

View check run for this annotation

Orca Security (US) / Orca Security - Infrastructure as Code

[HIGH] Controller of pods with role that allows the creation or modification of other pods 

Details:
The permission to create pods in a cluster should be restricted because it allows
privilege escalation.

Recommendation:
metadata.name=ci-teleport-sa.rules.verbs should not contain the value 'create'
when metadata.name=ci-teleport-sa.rules.resources contains the value 'pods'
---
# role to allow pod operations via impersonation in teletest namespace
apiVersion: rbac.authorization.k8s.io/v1
Expand All @@ -41,11 +41,11 @@
verbs: ["get", "list", "watch"]
resourceNames: ["test-pod"]
- apiGroups: [""]
resources: ["pods/exec"]

Check warning on line 44 in fixtures/ci-teleport-rbac/ci-teleport.yaml

View check run for this annotation

Orca Security (US) / Orca Security - Infrastructure as Code

[MEDIUM] Controller of pods with role that allows attaching or executing commands inside a pod 

Details:
Roles or ClusterRoles with RBAC permissions to run commands in containers via
'kubectl exec' could be abused by attackers to execute malicious code in case of
compromise. To prevent this, the 'pods/exec' verb should not be used in
production environments

Recommendation:
metadata.name={{ci-teleport-group}}.rules[1].resources should not include the
'pods/exec' resource
verbs: ["create"]
resourceNames: ["test-pod"]
- apiGroups: [""]
resources: ["pods/portforward"]

Check warning on line 48 in fixtures/ci-teleport-rbac/ci-teleport.yaml

View check run for this annotation

Orca Security (US) / Orca Security - Infrastructure as Code

[MEDIUM] RBAC Roles with Port-Forwarding Permission 

Details:
Roles or ClusterRoles with RBAC permissions to port-forward into pods can open
socket-level communication channels to containers. In case of compromise,
attackers may abuse this for direct communication that bypasses network security
restrictions

Recommendation:
metadata.name={{ci-teleport-group}}.rules[2].resources should not include the
'pods/portforward' resource
verbs: ["create"]
resourceNames: ["test-pod"]
- apiGroups: [""]
Expand All @@ -56,6 +56,10 @@
resources: ["pods/log"]
verbs: ["get"]
resourceNames: ["test-pod"]
- apiGroups: [""]
resources: ["pods/attach"]

Check warning on line 60 in fixtures/ci-teleport-rbac/ci-teleport.yaml

View check run for this annotation

Orca Security (US) / Orca Security - Infrastructure as Code

[MEDIUM] RBAC Roles with Attach Permission 

Details:
Roles or ClusterRoles with RBAC permissions to attach to containers via 'kubectl
attach' could be abused by attackers to read log output (stdout, stderr) and send
input data (stdin) to running processes. Additionally, it would allow a malicious
user to attach to a privileged container resulting in a privilege escalation
attack. To prevent this, the 'pods/attach' verb should not be used in production
environments

Recommendation:
metadata.name={{ci-teleport-group}}.rules[5].resources should not include the
'pods/attach' resource
verbs: ["create"]
resourceNames: ["test-pod"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
Expand Down
Loading