profile
viewpoint

aquasecurity/kube-hunter 2542

Hunt for security weaknesses in Kubernetes clusters

aquasecurity/tracee 533

Container and system event tracing using eBPF

aquasecurity/Hacktoberfest 20

Aqua Security's open source celebration for Hacktoberfest

itaysk/azure-tagowner 20

Automatically tag Azure resources with the user who created them

GoogleCloudPlatform/ubbagent 13

Metering agent

itaysk/AzureGC 12

Azure Garbage Collector - a governance tool to keep shared Azure subscription tidy (unmaintained, see readme)

Codefresh-Examples/Examples 6

Codefresh official examples repository

itaysk/envoy-playground 4

Play with Envoy Proxy

starteditaysk/kubectl-neat

started time in 6 hours

issue openedaquasecurity/tracee

Yesterday's release was tagged incorrectly (`v0.3` instead of `v0.3.X`)

It was tagged v0.3 instead of v0.3.X like the rest of the releases

created time in 15 hours

starteditaysk/kubectl-neat

started time in 15 hours

created repositorygarethr/snyket

created time in 20 hours

starteditaysk/kubectl-neat

started time in a day

starteditaysk/kubectl-neat

started time in a day

issue openedaquasecurity/tracee

Use alpine docker image instead of ubuntu

Moving to alpine will reduce ~50MB (non compressed) by installing the following packages for "fat" image:

FROM golang:alpine RUN apk update RUN apk add clang llvm make gcc libc6-compat coreutils linux-headers musl-dev elfutils-dev libelf-static zlib-static ...

And for "slim" image, will reduce the image size to less than 10MB (non compressed): FROM alpine RUN apk update RUN apk add libc6-compat elfutils-dev ...

Other advantages of moving to alpine: Faster CI times (as apk update and apk add are much faster than apt parallels), Smaller attack surface

If we choose to go in this path, we should also statically compile tracee as alpine uses musl. Statically compiling the code has its own advantages, as it will remove the libc and libelf dependencies

created time in a day

issue commentaquasecurity/tracee

Add filter comparison operation options (>, <, !=)

Ah, makes sense! Thanks for suggestions, working on it!

grantseltzer

comment created time in a day

issue commentaquasecurity/tracee

Add filter comparison operation options (>, <, !=)

We don't need to populate the map if removing configFilterByUid as we will support ">" operator, and default to uid>0. If no filter was chosen, bpf code checks uid filters and see that uid>0 was chosen and continues. If uid=xxx or uid!=xxx was given, then bpf code will just try to match.

grantseltzer

comment created time in 2 days

issue commentaquasecurity/tracee

reduce the size of docker images

Moving to alpine will reduce ~50MB (non compressed) by installing the following packages for fat:

FROM golang:alpine RUN apk update RUN apk add clang llvm make gcc libc6-compat coreutils linux-headers musl-dev elfutils-dev libelf-static zlib-static WORKDIR /

And for slim, will reduce the image size to less than 10MB (non compressed): FROM alpine RUN apk update RUN apk add libc6-compat elfutils-dev WORKDIR /

itaysk

comment created time in 2 days

issue commentaquasecurity/tracee

Add filter comparison operation options (>, <, !=)

The problem is that if don't use configFilterByUid we'd have to populate the content of every possible key/value in the map, right? Were you thinking that if --filter uid=1000 is specified uid_hash[1000] would be 1 and every other key's value would be 2? This is the reason I was thinking of having the operator in bpfConfigMap.

Otherwise, everything makes sense to me. Logical "and"ing < arguments with > arguments is a good idea.

grantseltzer

comment created time in 2 days

issue commentaquasecurity/tracee

Add filter comparison operation options (>, <, !=)

One more thing about uid==1000 and uid!=1000. In that case, we have to use a different value that will represent that both operator ls were chosen. This can be done by bitwise operations. If "=" have a value of 1 in the map, and "!=" Have a value of 2, we can "or" these values together: 1||2, which equals 3. Then, in the bpf code, we can check for equality by anding with "1", and for inequality by anding with 2

grantseltzer

comment created time in 2 days

issue commentaquasecurity/tracee

Add filter comparison operation options (>, <, !=)

Actually, I think configFilterByUid is not needed anymore. We can make a default filter of uid>=0 if non is chosen (which will capture all uids).

I also think that the conditions should be logical "and" and not "or" so uid>0 and uid>1000 should provide only uid>1000.

I don't think we should handle logical filters errors (like uid==1000 and uid!=1000 - in that case, no output will be shown by tracee (as logical anding these value gives an empty uid set)

grantseltzer

comment created time in 2 days

issue commentaquasecurity/tracee

Add filter comparison operation options (>, <, !=)

Sure, that is simpler. I can set the bpfConfigMap's 'configFilterByUid' field to the corresponding operator.

Have to make sure all the combination of filters are supported:

--filter uid=1000 --filter uid>5000 --filter uid>0 --filter uid<1000 --filter uid<1000 --filter uid!=0 --filter uid>0 --filter uid>1000(>0 overwrites >1000)--filter uid<1000 --filter uid<500(<1000 overwrites <500)--filter uid=1000 --filter uid!=1000` (error out? or second filter flag overwrites the first?)

grantseltzer

comment created time in 2 days

issue commentaquasecurity/tracee

Add filter comparison operation options (>, <, !=)

I don't know about using index 0 and 1 to store this metadata, as it requires special handling for these uids. I understand that the previous apprach I suggested is problematic? (using the value of the uid to store ">", "<"). I guess this is because it may be hard to know where to find the ">" and "<" uids in the map, right? (and we want to avoid loops where possible).

Let me suggest a different approach. We can use the uid_filter as we have today, and have 2 values (the key is the uid): "1" will represent "=" "2" will represent "!="

Then we can have a different map for "<" and ">" , which will have a limited size (say 3). Then, we can just "loop" over these 3 elements, and check if our given uid is bigger or smaller than, according to: "1" that will represent "<" "2" that will represent ">"

WDYT?

grantseltzer

comment created time in 2 days

starteditaysk/kubectl-neat

started time in 2 days

issue commentaquasecurity/tracee

Add filter comparison operation options (>, <, !=)

The way i'm thinking of going about this is as follows:

  • Use the BPF_HASH uid_filter to store both the 'operator' and the values to compare the process uid to.
  • uid_filter[0] contains the operator in first 3 bits (1 is '=', 2 is '!=', 3 is '>', 4 is '<')
  • If the operator is = or != the uid_filter hash works the way it does now
    • To avoid collisions (i.e. uid=0 is specified):
      • i'll >> 3 the value in the hash before checking if the uid matches.
      • When checking operator i'll && with FFFFFFF8
  • If the operator is > or < then uid_filter[1] contains the value to compare to.

I can also tune this to instead have operator values for multiple operators specified (i.e. uid<1000 and uid >5000) where uid_filter[2] contains the second value. I don't see too much usecase for supporting this but it couldn't hurt.

Let me know if you have any thoughts.

grantseltzer

comment created time in 2 days

issue closedaquasecurity/tracee

Filter by UID

extend the current --trace flag to support in-kernel filtering by user id, like so: --trace uid:1001

closed time in 3 days

itaysk

Pull request review commentaquasecurity/tracee

update readme for release

 Alternatively, you can pre-compile the eBPF program, and provide it to the `trac 2. `make bpf DOCKER=1` to build in a Docker container which includes all development tooling. 3. There is also a handy `make all` (and the `make all DOCKER=1` variant) which builds both the executable and the eBPF program. -Once you have the eBPF program artifact, you can provide it to Tracee in any of the locations mentioned above. In this case, the full Docker image can be replaced by the lighter-weight `aquasec/tracee:slim` image (this is unavilable at the moment and will be added to the next release). This image cannot build the eBPF program on its own, and is meant to be used when you already compiled the eBPF program beforehand, for example by adding the following mount to the docker run command: `-v /path/to/tracee.bpf.1_2_3.4_5_6.o:/tmp/tracee/tracee.bpf.1_2_3.4_5_6.o`.+Once you have the eBPF program artifact, you can provide it to Tracee in any of the locations mentioned above. In this case, the full Docker image can be replaced by the lighter-weight `aquasec/tracee:slim` image. This image cannot build the eBPF program on its own, and is meant to be used when you have already compiled the eBPF program beforehand.++#### Running in container++Tracee uses a filesystem directory, by default `/tmp/tracee` to capture runtime artifacts, internal components, and other miscellaneous. When running in a container, it's useful to mount this directory in, so that the artifacts are accessible after the container exists. For example, you can add this to the docker run command `-v /tmp/tracee:/tmp/tracee`.++If running in a container, regardless if it's the full or slim image, it's advisable to reuse the eBPF program across runs by mounting it from the host to the container. This way if the container builds the eBPF program it will be persisted on the host, and if the eBPF program already exists on the host, the container will automatically discover it. If you've already mounted the `/tmp/tracee` directory from the host, you're good to go, since Tracee by default will use this location for the eBPF program. You can also mount the eBPF program file individually if it's stored elsewhere (e.g in a shared volume), for example: `-v /path/to/tracee.ebpf.1_2_3.4_5_6.o:/some/path/tracee.ebpf.1_2_3.4_5_6.o -e TRACEE_BPF_FILE=/some/path`. ++When using the `--capture exec` option, Tracee needs access to the host PID namespace. For Docker, add `--pid=host` to the run command.++If you are building the eBPF program in a container, you'll need to make the kernel headers available in the container. The quickstart example has wide mounts that works in a variety of cases, for demonstration purposes. If you want, you can narrow those mounts down to a directory that contains the headers on your setup, for example: `-v /path/to/headers:/myheaders -e KERN_SRC=/myheaders`. As mentioned before, a better practice for production is to pre-compile the eBPF program, in which case the kernel headers are not needed at runtime. -### Permissions+#### Permissions -If you use the Tracee binary, you'll need to run it with root permissions in order to load the eBPF code. -If you use the Docker container, you should run it with the `--privileged` flag.+Tracee needs to run with sufficient privileges to load and attach the eBPF program. This means running as `root`, or with the `--privileged` flag if running with Docker.  +For better control, you can run with the specific capabilities `SYS_ADMIN` and `CAP_SYS_RESOURCE`.  

Starting from kernel 5.8, there are new CAP_BPF+CAP_TRACING which should be used instead of SYS_ADMIN CAP_SYS_RESOURCE is used to change the ulimit in order to be able to make bpf maps

itaysk

comment created time in 3 days

Pull request review commentaquasecurity/tracee

update readme for release

 Alternatively, you can pre-compile the eBPF program, and provide it to the `trac 2. `make bpf DOCKER=1` to build in a Docker container which includes all development tooling. 3. There is also a handy `make all` (and the `make all DOCKER=1` variant) which builds both the executable and the eBPF program. -Once you have the eBPF program artifact, you can provide it to Tracee in any of the locations mentioned above. In this case, the full Docker image can be replaced by the lighter-weight `aquasec/tracee:slim` image (this is unavilable at the moment and will be added to the next release). This image cannot build the eBPF program on its own, and is meant to be used when you already compiled the eBPF program beforehand, for example by adding the following mount to the docker run command: `-v /path/to/tracee.bpf.1_2_3.4_5_6.o:/tmp/tracee/tracee.bpf.1_2_3.4_5_6.o`.+Once you have the eBPF program artifact, you can provide it to Tracee in any of the locations mentioned above. In this case, the full Docker image can be replaced by the lighter-weight `aquasec/tracee:slim` image. This image cannot build the eBPF program on its own, and is meant to be used when you have already compiled the eBPF program beforehand.++#### Running in container++Tracee uses a filesystem directory, by default `/tmp/tracee` to capture runtime artifacts, internal components, and other miscellaneous. When running in a container, it's useful to mount this directory in, so that the artifacts are accessible after the container exists. For example, you can add this to the docker run command `-v /tmp/tracee:/tmp/tracee`.++If running in a container, regardless if it's the full or slim image, it's advisable to reuse the eBPF program across runs by mounting it from the host to the container. This way if the container builds the eBPF program it will be persisted on the host, and if the eBPF program already exists on the host, the container will automatically discover it. If you've already mounted the `/tmp/tracee` directory from the host, you're good to go, since Tracee by default will use this location for the eBPF program. You can also mount the eBPF program file individually if it's stored elsewhere (e.g in a shared volume), for example: `-v /path/to/tracee.ebpf.1_2_3.4_5_6.o:/some/path/tracee.ebpf.1_2_3.4_5_6.o -e TRACEE_BPF_FILE=/some/path`. 

tracee.ebpf.1_2_3.4_5_6.o -> ebpf -> bpf.

itaysk

comment created time in 3 days

Pull request review commentaquasecurity/tracee

update readme for release

 Alternatively, you can pre-compile the eBPF program, and provide it to the `trac 2. `make bpf DOCKER=1` to build in a Docker container which includes all development tooling. 3. There is also a handy `make all` (and the `make all DOCKER=1` variant) which builds both the executable and the eBPF program. -Once you have the eBPF program artifact, you can provide it to Tracee in any of the locations mentioned above. In this case, the full Docker image can be replaced by the lighter-weight `aquasec/tracee:slim` image (this is unavilable at the moment and will be added to the next release). This image cannot build the eBPF program on its own, and is meant to be used when you already compiled the eBPF program beforehand, for example by adding the following mount to the docker run command: `-v /path/to/tracee.bpf.1_2_3.4_5_6.o:/tmp/tracee/tracee.bpf.1_2_3.4_5_6.o`.+Once you have the eBPF program artifact, you can provide it to Tracee in any of the locations mentioned above. In this case, the full Docker image can be replaced by the lighter-weight `aquasec/tracee:slim` image. This image cannot build the eBPF program on its own, and is meant to be used when you have already compiled the eBPF program beforehand.++#### Running in container++Tracee uses a filesystem directory, by default `/tmp/tracee` to capture runtime artifacts, internal components, and other miscellaneous. When running in a container, it's useful to mount this directory in, so that the artifacts are accessible after the container exists. For example, you can add this to the docker run command `-v /tmp/tracee:/tmp/tracee`.

exists -> exits

itaysk

comment created time in 3 days

Pull request review commentaquasecurity/tracee

update readme for release

 Alternatively, you can pre-compile the eBPF program, and provide it to the `trac 2. `make bpf DOCKER=1` to build in a Docker container which includes all development tooling. 3. There is also a handy `make all` (and the `make all DOCKER=1` variant) which builds both the executable and the eBPF program. -Once you have the eBPF program artifact, you can provide it to Tracee in any of the locations mentioned above. In this case, the full Docker image can be replaced by the lighter-weight `aquasec/tracee:slim` image (this is unavilable at the moment and will be added to the next release). This image cannot build the eBPF program on its own, and is meant to be used when you already compiled the eBPF program beforehand, for example by adding the following mount to the docker run command: `-v /path/to/tracee.bpf.1_2_3.4_5_6.o:/tmp/tracee/tracee.bpf.1_2_3.4_5_6.o`.+Once you have the eBPF program artifact, you can provide it to Tracee in any of the locations mentioned above. In this case, the full Docker image can be replaced by the lighter-weight `aquasec/tracee:slim` image. This image cannot build the eBPF program on its own, and is meant to be used when you have already compiled the eBPF program beforehand.++#### Running in container

in a container (or from a container?)

itaysk

comment created time in 3 days

issue commentaquasecurity/tracee

Filter by UID

Created #328

itaysk

comment created time in 3 days

issue openedaquasecurity/tracee

Add filter comparison operation options (>, <, !=)

Now that the filter flag was merged in #315 it would be great to have more options besides '=' for matching on filters. For example:

--filter uid > 0

--filter uid != 1000

--filter return < 0

created time in 3 days

PR opened cncf/sig-security

typo: ref link error

^9 -> ^10

+1 -1

0 comment

1 changed file

pr created time in 3 days

issue commentaquasecurity/tracee

Filter by UID

@yanivagman I'm half way through a diff for filter operators, i'll have time to work on it Thursday and Friday so will submit it probably over the weekend. I'll open a new issue for it so we can close this one.

itaysk

comment created time in 3 days

Pull request review commentaquasecurity/tracee

explain mounting /tmp/tracee with docker

 Alternatively, you can pre-compile the eBPF program, and provide it to the `trac 2. `make bpf DOCKER=1` to build in a Docker container which includes all development tooling. 3. There is also a handy `make all` (and the `make all DOCKER=1` variant) which builds both the executable and the eBPF program. -Once you have the eBPF program artifact, you can provide it to Tracee in any of the locations mentioned above. In this case, the full Docker image can be replaced by the lighter-weight `aquasec/tracee:slim` image (this is unavilable at the moment and will be added to the next release). This image cannot build the eBPF program on its own, and is meant to be used when you already compiled the eBPF program beforehand, for example by adding the following mount to the docker run command: `-v /path/to/tracee.bpf.1_2_3.4_5_6.o:/tmp/tracee/tracee.bpf.1_2_3.4_5_6.o`.+Once you have the eBPF program artifact, you can provide it to Tracee in any of the locations mentioned above. In this case, the full Docker image can be replaced by the lighter-weight `aquasec/tracee:slim` image (this is unavailable at the moment and will be added to the next release). This image cannot build the eBPF program on its own, and is meant to be used when you have already compiled the eBPF program beforehand.++If running in a Docker container, regardless if it's the full or slim image, it's advisable to reuse the eBPF program across runs by mounting it from the host to the container. To make things easy, you can mount the entire `/tmp/tracee` directory into the container, so that if the container builds the eBPF program is will be persisted on the host, and if the eBPF program already exists on the host, the container can automatically discover it, for example `-v /tmp/tracee:/tmp/tracee`. This practice is helpful also to examine the output directory that Tracee creates under this path.

"is will be persisted on the host" -> it ... or "it will persist on the host"

itaysk

comment created time in 3 days

Pull request review commentaquasecurity/tracee

explain mounting /tmp/tracee with docker

 Not required if pre-compiling the eBPF code (see [Installation options](#install ### Quickstart with Docker  ```bash-docker run --name tracee --rm --privileged --pid=host -v /lib/modules/:/lib/modules/:ro -v /usr/src:/usr/src:ro aquasec/tracee+docker run --name tracee --rm --privileged --pid=host -v /lib/modules/:/lib/modules/:ro -v /usr/src:/usr/src:ro -v /tmp/tracee:/tmp/tracee aquasec/tracee ``` +> Note: You may need to change the volume mounts for the kernel headers based on your setup.

Maybe add to this note something about KERN_SRC

itaysk

comment created time in 3 days

Pull request review commentaquasecurity/tracee

explain mounting /tmp/tracee with docker

 Alternatively, you can pre-compile the eBPF program, and provide it to the `trac 2. `make bpf DOCKER=1` to build in a Docker container which includes all development tooling. 3. There is also a handy `make all` (and the `make all DOCKER=1` variant) which builds both the executable and the eBPF program. -Once you have the eBPF program artifact, you can provide it to Tracee in any of the locations mentioned above. In this case, the full Docker image can be replaced by the lighter-weight `aquasec/tracee:slim` image (this is unavilable at the moment and will be added to the next release). This image cannot build the eBPF program on its own, and is meant to be used when you already compiled the eBPF program beforehand, for example by adding the following mount to the docker run command: `-v /path/to/tracee.bpf.1_2_3.4_5_6.o:/tmp/tracee/tracee.bpf.1_2_3.4_5_6.o`.+Once you have the eBPF program artifact, you can provide it to Tracee in any of the locations mentioned above. In this case, the full Docker image can be replaced by the lighter-weight `aquasec/tracee:slim` image (this is unavailable at the moment and will be added to the next release). This image cannot build the eBPF program on its own, and is meant to be used when you have already compiled the eBPF program beforehand.++If running in a Docker container, regardless if it's the full or slim image, it's advisable to reuse the eBPF program across runs by mounting it from the host to the container. To make things easy, you can mount the entire `/tmp/tracee` directory into the container, so that if the container builds the eBPF program is will be persisted on the host, and if the eBPF program already exists on the host, the container can automatically discover it, for example `-v /tmp/tracee:/tmp/tracee`. This practice is helpful also to examine the output directory that Tracee creates under this path.

"you can mount the entire /tmp/tracee directory...." Maybe add "(or any other directory)"?

itaysk

comment created time in 3 days

more