Reasonable to set up Vault on AWS ECS or Fargate?

[Konrad Reiche]

Hi,

I am about to configure Vault for our production environment and I was wondering whether it makes sense to set up Vault as a container. Especially, since AWS Fargate is now out I was wondering if I should be concerned of anything choosing this as the environment. Someone pointed out, that "the threat model of Vault does not cover running it on shared tenancy with Linux containers". But isn't that true for normal EC2 instances as well?

Best,
Konrad

[Jason Martin]

Particularly to Fargate, consider that you will have much less
control over the lifetime of a container. This may be relevant
to how you unseal vaults; you'll have less control over when an
unsealing is required.

-Jason Martin

[Konrad Reiche]

Why do I have less control over the lifetime of a container? Does Fargate randomly terminate containers as needed?

--

This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.

GitHub Issues: https://github.com/hashicorp/vault/issues

IRC: #vault-tool on Freenode

---

You received this message because you are subscribed to the Google Groups "Vault" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/20180512162518.GA31503%40toger.us.

For more options, visit https://groups.google.com/d/optout.

[Jason Martin]

On Sat, May 12, 2018 at 10:31:43AM -0700, Konrad Reiche wrote:
> Why do I have less control over the lifetime of a container? Does Fargate randomly terminate containers as needed?

Yes. In Fargate, AWS owns the underlying node and its
maintenance. Unlike EC2 there is no concept of a 'scheduled node
maintenance'; it'll just go away. I've heard from the ECS
product team that they expect that container lifetimes will
naturally be short enough generally that they can just not
schedule new containers on a node that needs some sort of
maintenance, but long-lived Vault instances might not fit that
profile. So, containers that cannot reprovision automatically
(unless you have the paid version and use HSM-unsealing) are a
more daunting.

-Jason Martin

[Konrad Reiche]

Thanks Jason,

I also realized that Fargate doesn't really make sense for containers that you want to run 24/7 as the price model seems to amortizes for short-lived containers where the need is to scale them arbitrarily based on traffic but not for something as static as Vault.

Best,

Konrad

--

This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.

GitHub Issues: https://github.com/hashicorp/vault/issues

IRC: #vault-tool on Freenode

---

You received this message because you are subscribed to the Google Groups "Vault" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/20180514173949.GA1734%40toger.us.

[Justin DynamicD]

Echoing/re-enforcing the pricing model challenge.  Fargate will run roughly twice the price as a traditional EC2 instance if left running for a month.  It's just not modeled for long-term persistent containers.   That may change once they pull their managed Kubernetes platform out of preview, but for now that's a real consideration.

If HSM auto-unseal ever makes it into the free version that would be awesome, but if it doesn't, there are a number of blogs out there where people store the unseal keys in ssm:parameterstore and have them queried/unsealed auto magically that way.  I'd look into such a scenario, otherwise, I'd just use a traditional AMI and avoid the "why are all my nodes sealed" risk.

[Jason Martin]

On Tue, May 15, 2018 at 03:09:35PM -0700, Justin DynamicD wrote:
> Echoing/re-enforcing the pricing model challenge. Fargate will run roughly
> twice the price as a traditional EC2 instance if left running for a month.
> It's just not modeled for long-term persistent containers. That may
> change once they pull their managed Kubernetes platform out of preview, but
> for now that's a real consideration.

Fargate at scale is appealing though since it means not spending
any time on node maintenance (patching, configuration) or node scaling,
which makes a higher per-unit cost acceptable.

-Jason Martin

> > email to vault-tool+...@googlegroups.com <javascript:>.

> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/vault-tool/20180514173949.GA1734%40toger.us
> > .
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
>
> --
> This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/0240d130-c704-4b17-b770-84d7e3c25c7f%40googlegroups.com.

[Justin DynamicD]

True, but compare that to managed k8s on Azure where it's 100% managed yet you still pay per node at the same rate.  So they literally give you free managed k8s.  fargate is nice from the perspective that it is 100% abstracted and I don't even worry about cluster count, but when that's literally the _only_ thing I worry about on a managed k8s instance (and I' m assuming AWS will match this due to google/azure pressure) I'm still hesitant to push Fargate very hard until AWS catches up here.