
Awless: A Mighty CLI for AWS - dcu
https://github.com/wallix/awless
======
openasocket
I hate to pile on to the complaints about sending usage metrics to a server,
but this is pretty funky. The metrics include the instance id, account id, a
list of the commands run with timestamps, the region, a bunch of metadata
about the number of VPCs, Subnets, IAM users and policies, etc. Which is kind
of a lot to get, and definitely isn't anonymous. Why do they need to know how
many VPCs, Subnets, IAM users, and IAM roles I have?

Then there's how the data is sent. The metrics are converted to JSON, gzipped,
then AES encrypted with a random key. The random key is then encrypted with a
constant public key. the encrypted key and encrypted payload are serialized
into some JSON, and is then POST-ed to an HTTPS URL. This seems unnecessarily
convoluted, and even with my meager knowledge of crypto I already see some
problems (compressing then encrypting is a no-no) which could spell trouble.
Shouldn't you just need to upload the JSON of the metrics over an SSL
connection?

~~~
mcherm
> compressing then encrypting is a no-no

Perhaps it is just my own meager understanding of cryptography, but I didn't
know of anything that would make this a bad idea. Can you explain why it is
potentially a problem?

~~~
LeoPanthera
The "CRIME" exploit relied on encrypted compressed data.
[https://en.wikipedia.org/wiki/CRIME_(security_exploit)](https://en.wikipedia.org/wiki/CRIME_\(security_exploit\))

~~~
mcherm
Thanks, that was quite helpful.

I would say that "compress, then encrypt is bad" is the wrong message to take
away from this type of vulnerability. In the case of CRIME in particular, the
issue was that:

1\. The attacker provided part of the message. 2\. The rest of the message
contained a secret. 3\. The entire message (attacker-provided-part and secret)
were compressed together.

We can stop there; the length of the compressed data now contains information
about the similarity between the attacker-provided content and the secret.

The correct lesson to take away from this is "do not compress a combination of
attacker-provided content and secrets". Compressing before encrypting is
perfectly sensible. (And, by the way, compressing after encrypting isn't
better, it is useless since your encrypted content ought to be
incompressible.)

------
heartsucker
> We also collect a few anonymous data (CLI errors, most frequently used
> commands and count of resources).

Looks cool, but this is an instant no for me. Sorry guys.

~~~
hbbio
Project creator here (but obviously not the OP).

Yes, we do collect minimal anonymised statistics in the sole goal of improving
awless. All the statistics code is here:
[https://github.com/wallix/awless/blob/master/stats/stats.go](https://github.com/wallix/awless/blob/master/stats/stats.go)

As the project is Apache licensed, you're free to modify it if you don't want
this. Also, if you're conscious about privacy you should use application
firewalls on your client side like Little Snitch etc. since many software that
you install on your machine also do this.

~~~
scaryclam
I like the look of this, so on the software side it's a thumbs up.

However, the fact that the code is active at all will rule it out for some
companies (firewall or not).

Perhaps make it something users can turn off in a config file? Not everyone
can code in go, especially if their job is as a sysadmin, which isn't unlikely
given that this is an infrastructure tool, so it might not be as simple as
forking and editing the code for them.

~~~
mbreese
Or make it turn-off-able (?) with an environmental variable. There are a
couple of ways to make the tool default to report and allowable in non-
reportable environments. The key thing is to make what is happening
transparent.

~~~
frugalmail
Must be an explicit "turn-on" option.

------
vitalysh
Just wondering here, but why would you use this vs terraform? Given that I can
define most of the stuff I need from AWS in terraform and check the state of
the infra via plan command, what would be the use case for CLI? I'm actively
trying to break the habit of modifying infra without first writing terraform
document for it. This way I can always be sure that I have no surprises when
creating a new environment.

~~~
skywhopper
Terraform can't tell you about the stuff it doesn't know about.

~~~
vitalysh
And this is exactly what I'm trying to avoid. Terraform should know about most
of the stuff.

------
jsk2600
Sorry for off-topic question, but is this considered good golang code ?
[https://github.com/wallix/awless/blob/master/stats/stats.go](https://github.com/wallix/awless/blob/master/stats/stats.go)

I'm considering learning go but amount of 'return err' and 'return nil, 0,
err' is instant turn-off. Is this best-practice error handling in go ? Thanks
!

~~~
sly010
It's pretty normal and you will get used to it quickly. Thanks to this pattern
it's very hard to ignore errors.

The only think that could be done better is instead of always blindly
returning an error, one could wrap them in higher level errors and build a
sort of error trace:

E.g:

    
    
      - task failed because
       - authentication failed because
        - could not load credentials because
         - because file xy.pem is not readable
    

But instead of the above, you often just receive a "permission error", but you
don't know where it came from, which can make debugging hard.

Edit: formatting

~~~
jsk2600
Thank you !

>instead of always blindly returning an error, one could wrap them in higher
level errors and build a sort of error trace

Isn't that basically just reinventing exceptions, sort-of ?

~~~
sly010
Basically. It's a little different because you have more control. It's way too
easy to assume exceptions won't happen and basically ignore them. But they
happen in unexpected places (e.g. every time when dealing with IO).

Exceptions only contain a function call trace (stack of function calls), while
a logical error trace is more like an explicit try/catch/wrap/throw around
every call and could be more informative to the end user if done properly.

------
rkeene2
How about some instructions on building it ?

It lacks a Makefile or any documentation in the tarball for the latest release
(v0.0.13)...

I found some sparse documentation on the wiki, but that appears to fail. I
tried: GOPATH=$(pwd) go build .

And got: $ GOPATH=$(pwd) go build . main.go:19:8: cannot find package
"github.com/wallix/awless/commands" in any of:
/usr/src/github.com/wallix/awless/commands (from $GOROOT)
/home/rkeene/Downloads/awless-0.0.13/src/github.com/wallix/awless/commands
(from $GOPATH)

~~~
simbit
It seems your GOPATH is not set correctly. First freshly install Go
independently. Verify it is installed correctly with "go env".

Then do a "go get github.com/wallix/awless", "cd
$GOPATH/src/github.com/wallix/awless" and "go install".

Then in the same prompt do "awless"

~~~
rkeene2
I downloaded the release tarball, so why would I also use "go get" to get the
source I just downloaded ?

~~~
cridenour
"go get" will download dependencies. You can also cd to the source as run "go
get ."

~~~
rkeene2
I can fetch the dependencies myself as well. Is there documentation on which
packages are depended-on, including release version ranges ?

------
ak217
If anyone is interested in a more minimalistic alternative to this, I have
been designing an "as simple as possible, but no simpler" devops toolkit and
CLI on top of the AWS CLI:
[https://github.com/kislyuk/aegea](https://github.com/kislyuk/aegea)

------
010a
Looks great. My main complaint is that the templates feature appears to be
reinventing Terraform. Would have been cool if we could use the Terraform
templates we already have, or even provide support for CloudFormation (given
this is an AWS-only tool).

~~~
hbbio
Thanks for your feedback.

awless is currently in its early life. We also plan to support both
CloudFormation (first) and maybe Terraform at some point. CF and TF are
exhaustive but more complex than awless templates.

awless is meant to simplify how we can create and manage an AWS infrastructure
(which is originally our own need at Wallix), and we wanted to have simple
templates as part of the CLI.

------
djhworld
Can someone explain why this is different/better than the official CLI
application?

~~~
scaryclam
For me, the output is friendlier, which is great if you're just trying to make
a quick query about the running instances or something.

However, the whole thread above pointing out the data collection issues makes
me far less likely to be moving away from the official cli + bash magic any
time soon

~~~
dipthegeezer
I concur, I really don't see what value this brings over the official aws cli.

------
yumaikas
The constant -less-ness of operations type tools these days is starting to get
rather funny.

~~~
vacri
The state of being without a cutlass is 'cutlasslessness'!

------
aidos
This looks great. I use the boto tools for all my aws stuff but they're clumsy
for working in an interactive fashion like this. Going to install now to have
a play!

------
dkersten
Looks really slick. From my brief glance though it doesn't support the two
things I love about the officials CLI: the filter and query facilities.

~~~
fxaguessy
(I'm one of the core developpers of awless). We are going to add filters and
queries very soon. We built awless by relying on RDF to represent the cloud
resources. As a result, in addition to simple filters on the properties, we
can also represent more complex queries such as "everthing inside a VPC", "the
siblings of an instance", etc. Try the `awless show` command to have an
insight of what we can do.

~~~
dkersten
That sounds fantastic, thanks!

------
Techbrunch
Currently I'm using: [https://github.com/awslabs/aws-
shell](https://github.com/awslabs/aws-shell) and I love it

------
eugenejen
i like that RDF to sync states from between local and remote. Nice to see
similar idea that I had for while to have a client for AWS that sync states
between AWS and local.

------
nimrody
How do you manage multiple environments (staging / production) with these type
of tools? How do you avoid making changes in the wrong environment?

~~~
hbbio
As of now, you can create a template to deploy an environment, and for
instance create one master node (for instance a subnet) for each environment.

The missing values in the template (aka "holes" will be asked for by awless),
so you can have staging and production deployments.

Note that we just released the project last Friday, and in particular have an
ambitious roadmap for the templates. For instance, we could password protect
accessing some nodes, and prevent wrong actions on the production env.

------
johnmarcus
"We also collect a few anonymous data (CLI errors, most frequently used
commands and count of resources)." Nope.

------
janwillemb
It should have been named "claws"

------
ne01
For those who have experience with both, I wonder how does it compare with
gcloud CLI?

------
pmig
I would love to see a package in AUR. Are there more Arch people over here?

------
dkarapetyan
Finally some competition for Terraform.

~~~
scaryclam
The trust has already been broken by this project, so I don't see it even
getting traction, nevermind becoming competition.

~~~
dkarapetyan
It's open source. You can fork and disable the tracking.

------
the_arun
Nice!! Thanks for sharing @dcu

------
simplehuman
To all those complaining about collection of stats: Pretty much _every_ SaaS
company is collecting stats about your behavior. It seems a bit off that there
is so much rage about a project whose code is out their in the open to collect
stats.

Point me to atleast a single popular SaaS product that does not have analytics
in it's page.

~~~
Terretta
What part of "Awsless: A Mighty CLI for AWS" sounds like SaaS?

"SaaS" means software as a service, something someone else runs, generally web
based where metrics are relevant, not a command line tool on your own machine
talking to your own infra.

From read me:

Install

Choose one of the following options:

\- Download the latest awless binaries (Windows/Linux/macOS) from Github

\- If you have Golang already installed, build the source with: go get
github.com/wallix/awless

\- On macOS, use homebrew: brew tap wallix/awless; brew install awless

Which of those sounds like SaaS?

~~~
simplehuman
Not sure how to respond. I wasn't comparing awsless to a SaaS at all. I was
saying that SaaS collects info about you all the time and I don't see anyone
going up in arms about that.

According to you, it's OK to collect data if the software is on another
person's infra.

~~~
1_2__3
Yes, you compared them, or rather, compared the reactions of people to them.
If you aren't implying by extension that SaaS and awsless are comparable then
your argument makes no sense.

