[Cloud-init-dev] [Bug 1835114] Re: [MIR] ec2-instance-connect

[Ryan Harper]

On Thu, Feb 13, 2020 at 6:20 AM Balint Reczey <balint.reczey at canonical.com>
wrote:

> @raharper I agree with the concern regarding the manipulation of sshd
> config. To minimize the collision with cloud-init this package does not
> change /etc/ssh/sshd_config like cloud-init does, but overrides the
> configuration value with a systemd drop-in. The drop-in is placed at the
>

This does not avoid a collision with cloud-init.  That is, the current
implementation
is to modify the arguments passed to sshd instead of making changes to sshd
config.
Multiple sources of configuration is still an issue.  Someone inspecting
sshd config will
not see that the AuthorizedKeyCommand is being passed via arguments,
further they
may not know where this additional override is coming from w.r.t the
systemd drop-in
config.  If a user (or program via cloud-init config) were to modify sshd
config and
set their own AuthorizedKeyCommand, this scenario will fail for them since
the
ec2-instance-connect drop in will always take precedence.

Shouldn't the drop-in program examine sshd config?


> Regarding the potential user confusion when the user also sets ssh keys
> using cloud-init eic_run_authorized_keys is designed to _merge_ the keys
> used by Instance Connect with the other keys in use thus the users can
> continue to use their keys deployed by cloud-init or the ones deployed
> by other means.
>

Could you elaborate (or point to documentation) on this merging?   I'm
familiar
with how AuthorizedKeyCommand works if it does not produce any output, sshd
will fall back to AuthorizedKey files specifiedin sshd_config; but I've not
seen any
discussion on the merging you suggest.


>
> I also agree that there is additional overhead for each ssh connection,
> but while testing the package I have not found that excessive. We may
>

Instead of vague statements, capturing actual values would be most
useful.


> need further evaluation of the impact on the ssh service before adding
> the package to the AMIs by default, but I think this can be done after
> finishing the MIR process.
>

I generally disagree with letting something in to main that we want to
support
and "we can fix this after we agree to MIR".


>
> Upstream already answered @paelzer's caching proposal, and the package
> is installed on Amazon Linux 2 by default already, thus I believe
> upstream's attention is warranted regarding the overhead.
>

The response is dismissive; security and usability override any concern
around
overhead of the "security" feature.  This reinforces the need to benchmark
the
actual overhead per connection with synthetic and actual workloakds (I
suspect
something like a juju deployment to Ec2 of something like k8s or the like
mode
with lots of instances would be a reasonable workload to compare with and
without
the instance connect enabled.

Ryan

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ec2-instance-connect in Ubuntu.
https://bugs.launchpad.net/bugs/1835114

Title:
  [MIR] ec2-instance-connect

Status in ec2-instance-connect package in Ubuntu:
  Incomplete

Bug description:
  [Availability]
  ec2-instance-connect is in the Ubuntu archive, and available for all supported releases. It is available on all architectures despite only being useful on Amazon EC2 instances.

  [Rationale]
  This package is useful on Amazon EC2 instances to make use of a new feature:
  Instance Connect; which allows storing SSH keys for access online in the Amazon systems. These SSH keys are then retrieved to be used by the system's SSH service, collated with pre-existing keys as deployed on the system.

  Installing the package enables the use of Instance Connect on an
  instance.

  [Security]
  This is a new package, and as such has no security history to speak of.

  [Quality Assurance]
  The package consists in a few shell scripts that are difficult to test by
  themselves due to the high reliance on Amazon's Instance Connect service;
  which is online and limited to use on Amazon instances.

  Given that it's a new package, there are no long-term outstanding bugs in
  Ubuntu or Debian. The package is only maintained in Ubuntu at the moment.

  This package deals with special "hardware"; it is only useful on Amazon
  instances, and its support is required as a default deployment on such
  instances when deployed with Ubuntu.

  [UI Standards]
  Not applicable. This service is command-line only and has no configuration options.

  [Dependencies]
  There are no special dependencies to speak of.

  [Standards Compliance]
  This package has been thoroughly reviewed by a few Canonical engineers, there are no standards violations known.

  [Maintenance]
  This package is to be owned by the Ubuntu Foundations team.

  [Background Information]
  This is Amazon-specific, as previously mentioned.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ec2-instance-connect/+bug/1835114/+subscriptions