-
Notifications
You must be signed in to change notification settings - Fork 2.7k
/
CODEOWNERS
Validating CODEOWNERS rules...
235 lines (235 loc) · 11.2 KB
/
CODEOWNERS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
# Code owners are used by the Cilium community to consolidate common knowledge
# into teams that can provide consistent and actionable feedback to
# contributors. This section will describe groups of teams and suggestions
# about the focus areas for review.
#
# The primary motivation for these teams is to provide structure around review
# processes to ensure that contributors know how to reach out to community
# members to conduct discussions, ensure contributions meet the expectations of
# the community, and align on the direction of proposed changes. Furthermore,
# while these teams are primarily drawn upon to provide review on specific pull
# requests, they are also encouraged to self-organize around how to make
# improvements to their areas of the Cilium project over time.
#
# Any committer may self-nominate to code owner teams. Reach out to the core
# team on the #committers channel in Slack to coordinate. Committers do not
# require expert knowledge in an area in order to join a code owner team,
# only a willingness to engage in discussions and learn about the area.
#
# Project-wide
# ++++++++++++
#
# These code owners may provide feedback for Pull Requests submitted to any
# repository in the Cilium project:
#
# - @cilium/api:
# Ensure the backwards-compatibility of Cilium REST and gRPC APIs, excluding
# Hubble which is owned by @cilium/sig-hubble-api.
# - @cilium/build:
# Provide feedback on languages and scripting used for build and packaging
# system: Make, Shell, Docker.
# - @cilium/cli:
# Provide user experience feedback on changes to Command-Line Interfaces.
# These owners are a stand-in for the user community to bring a user
# perspective to the review process. Consider how information is presented,
# consistency of flags and options.
# - @cilium/ci-structure:
# Provide guidance around the best use of Cilium project continuous
# integration and testing infrastructure, including GitHub actions, VM
# helpers, testing frameworks, etc.
# - @cilium/contributing:
# Encourage practices that ensure an inclusive contributor community. Review
# tooling and scripts used by contributors.
# - @cilium/docs-structure:
# Ensure the consistency and layout of documentation. General feedback on the
# use of Sphinx, how to communicate content clearly to the community. This
# code owner is not expected to validate the technical correctness of
# submissions. Correctness is typically handled by another code owner group
# which is also assigned to any given piece of documentation.
# - @cilium/sig-foundations:
# Review changes to the core libraries and provide guidance to overall
# software architecture.
# - @cilium/github-sec:
# Responsible for maintaining the security of repositories in the Cilium
# project by maintaining best practices for workflow usage, for instance
# preventing malicious use of GitHub actions.
# - @cilium/helm:
# Provide input on the way that Helm can be used to configure features. These
# owners are a stand-in for the user community to bring a user perspective to
# the review process. Ensure that Helm changes are defined in manners that
# will be forward-compatible for upgrade and follow best practices for
# deployment (for example, being GitOps-friendly).
# - @cilium/sig-hubble-api:
# Review all Hubble API related changes. The Hubble API covers gRPC and
# metrics endpoints. The team ensures that API changes are backward
# compatible or that a new API version is created for backward incompatible
# changes.
# - @cilium/metrics:
# Provide recommendations about the types, names and labels for metrics to
# follow best practices. This includes considering the cardinality impact of
# metrics being added or extended.
# - @cilium/security:
# Provide feedback on changes that could have security implications for Cilium,
# and maintain security-related documentation.
# - @cilium/tophat:
# Top Hat duties rotate between the committer group from week to week, and
# they may assist in maintenance, triage and backporting duties across
# different Cilium repositories. Catch-all for code not otherwise owned by a
# team.
# - @cilium/vendor:
# Review vendor updates for software dependencies to check for any potential
# upstream breakages / incompatibilities. Discourage the use of unofficial
# forks of upstream libraries if they are actively maintained.
#
# Repository Owners
# +++++++++++++++++
#
# The following code owners are responsible for a range of general feedback for
# contributions to specific repositories:
#
# - @cilium/sig-hubble:
# Review all Cilium and Hubble code related to observing system events,
# exporting those via gRPC protocols outside the node and outside the
# cluster. those event channels, for example via TLS.
# - @cilium/hubble-ui:
# Maintain the Hubble UI graphical interface.
# - @cilium/tetragon:
# Review of all Tetragon code, both for Go and C (for eBPF).
#
# The teams above are responsible for reviewing the majority of contributions
# to the corresponding repositories. Additionally, there are "maintainer" teams
# listed below which may not be responsible for overall code review for a
# repository, but they have administrator access to the repositories and so
# they can assist with configuring GitHub repository settings, secrets, and
# related processes. For the full codeowners for individual repositories, see
# the CODEOWNERS file in the corresponding repository.
#
# - @cilium/cilium-cli-maintainers
# - @cilium/cilium-maintainers
# - @cilium/cilium-packer-ci-build-maintainers
# - @cilium/ebpf-lib-maintainers
# - @cilium/hubble-maintainers
# - @cilium/image-tools-maintainers
# - @cilium/metallb-maintainers
# - @cilium/openshift-terraform-maintainers
# - @cilium/proxy-maintainers
# - @cilium/tetragon-maintainers
#
# Cloud Integrations
# ++++++++++++++++++
#
# The following codeowner groups provide insight into the integrations with
# specific cloud providers:
#
# - @cilium/alibabacloud
# - @cilium/aws
# - @cilium/azure
#
# Cilium Internals
# ++++++++++++++++
#
# The following codeowner groups cover more specific knowledge about Cilium
# Agent internals or the way that particular Cilium features interact with
# external software and protocols:
#
# - @cilium/docker:
# Maintain the deprecated docker-plugin.
# - @cilium/endpoint:
# Provide background on how the Cilium Endpoint package fits into the overall
# agent architecture, relationship with generation of policy / datapath
# constructs, serialization and restore from disk.
# - @cilium/ipcache:
# Provide background on how the userspace IPCache structure fits into the
# overall agent architecture, ordering constraints with respect to network
# policies and encryption. Handle the relationship between Kubernetes state
# and datapath state as it pertains to remote peers.
# - @cilium/ipsec:
# Maintain the kernel IPsec configuration and related eBPF logic to ensure
# traffic is correctly encrypted.
# - @cilium/kvstore:
# Review Cilium interactions with key-value stores, particularly etcd.
# Understand the client libraries used by Cilium for sharing state between
# nodes and clusters.
# - @cilium/loader:
# Maintain the tooling that allows eBPF programs to be loaded into the
# kernel: LLVM, bpftool, use of cilium/ebpf for loading programs in the
# agent, ELF templating, etc.
# - @cilium/operator:
# Review operations that occur once per cluster via the Cilium Operator
# component. Take care of the corresponding garbage collection and leader
# election logic.
# - @cilium/proxy:
# Review low-level implementations used to redirect and process traffic at
# Layer 7, including via the Cilium DNS proxy and Envoy. Maintain the
# configurations for Envoy via xDS protocols as well as the extensible
# proxylib framework for Go-based layer 7 filters.
# - @cilium/sig-agent:
# Provide Cilium (agent) general Go review. Internal architecture, core data
# structures and daemon startup.
# - @cilium/sig-bgp:
# Review changes to our BGP integration.
# - @cilium/sig-clustermesh:
# Ensure the reliability of state sharing between clusters to ensure that
# each cluster maintains a separate fault domain.
# - @cilium/sig-datapath:
# Provide feedback on all eBPF code changes, use of the kernel APIs for
# configuring the networking and socket layers. Coordination of kernel
# subsystems such as xfrm (IPsec), iptables / nftables, tc. Maintain the
# control plane layers that populate most eBPF maps; account for endianness
# and system architecture impacts on the datapath code.
# - @cilium/sig-hubble:
# Review all Cilium and Hubble code related to observing system events,
# exporting those via gRPC protocols outside the node and outside the
# cluster. Ensure the security of those event channels, for example via TLS.
# - @cilium/sig-ipam:
# Coordinate the implementation between all of the IP Address Management
# modes, provide awareness/insight into IP resource exhaustion and garbage
# collection concerns.
# - @cilium/sig-k8s:
# Provide input on all interactions with Kubernetes, both for standard
# resources and CRDs. Ensure best practices are followed for the coordination
# of clusterwide state in order to minimize memory usage.
# - @cilium/sig-lb:
# Maintain the layers necessary to coordinate all load balancing
# configurations within the agent control plane, including Services,
# ClusterIP, NodePorts, Maglev, local redirect policies, and
# NAT46/NAT64.
# - @cilium/sig-policy:
# Ensure consistency of semantics for all network policy representations.
# Responsible for all policy logic from Kubernetes down to eBPF policymap
# entries, including all intermediate layers such as the Policy Repository,
# SelectorCache, PolicyCache, CachedSelectorPolicy, EndpointPolicy, etc.
# - @cilium/sig-servicemesh:
# Provide input on the way that Service Mesh constructs such as Gateway API
# are converted into lower-level constructs backed by eBPF or Envoy
# configurations. Maintain the CRDs necessary for Service Mesh functionality.
# - @cilium/wireguard:
# Maintain the kernel WireGuard configuration and datapath impacts related to
# ensuring traffic is encrypted correctly when WireGuard mode is enabled.
#
# END_CODEOWNERS_DOCS
#
# The following filepaths should be sorted so that more specific paths occur
# after the less specific paths, otherwise the ownership for the specific paths
# is not properly picked up in Github.
* @cilium/tophat
/.github/workflows/ @cilium/github-sec @cilium/ci-structure
/.github/workflows/*datapath*.yaml @cilium/sig-datapath @cilium/github-sec @cilium/ci-structure
/api/ @cilium/api
/api/v1/Makefile @cilium/sig-hubble-api
/api/v1/Makefile.protoc @cilium/sig-hubble-api
/api/v1/flow/ @cilium/sig-hubble-api
/api/v1/health/ @cilium/api
/api/v1/observer/ @cilium/sig-hubble-api
/api/v1/operator/ @cilium/api
/api/v1/peer/ @cilium/sig-hubble-api
/api/v1/recorder/ @cilium/sig-hubble-api
/api/v1/relay/ @cilium/sig-hubble-api
/images @cilium/build
/images/builder/install-protoc.sh @cilium/sig-hubble-api
/images/builder/install-protoplugins.sh @cilium/sig-hubble-api
/images/builder/update-cilium-builder-image.sh @cilium/github-sec
/images/runtime/update-cilium-runtime-image.sh @cilium/github-sec
/pkg/byteorder/ @cilium/api
/pkg/client @cilium/api
/pkg/hubble/metrics @cilium/sig-hubble-api