Instance level access revocation (blacklisting)

[Yann Mahé]

Hello,

I came across Confidant while looking for a secure credential storage service, and really liked the concepts: specifically how it uses AWS KMS & IAM to authenticate the different services.

However, diving a little more into it, I realized that this mechanism could also make instance revocation (blacklisting) access to a service difficult (impossible?). 

For instance, let's consider the scenario where an EC2 instance is suspected to be comprised. One may want to prevent it from accessing any credential. To do it, one can:

1. Kill the instance (for lack of being able to remove the IAM role of a running instance)

2. Remove the entire role from the service in Confidant. Downside: this would impact other instances as well :/

3. Do anything else?

I am not satisfied by 1 nor 2. Confidant does not seem to provide a solution either. 

Is this a scenario that you considered? If so, I'd appreciate hearing about your experience.

Thanks!

Yann

[Ryan Lane]

It depends on what your concern is here. If it's from the perspective of isolating a compromised node: Yeah, that's the case, but it's the case for IAM access as a whole. One approach is to network isolate the instance, by changing its security groups to a security group with limited (or no) egress allowed.

If this is more of a concern of having to tie the confidant services to IAM roles, and that those roles are tied to individual instances: a confidant service is by default 1:1 with IAM roles, but it doesn't necessarily need to be. The default is for confidant to manage grants on the authnz key and for those grants to reflect IAM roles, but you can manage the IAM policy directly as well.

Let's say for instance you have a service: example-production-iad, and you want to grant access to this confidant service to multiple IAM roles: instance1-production, instance2-production, instance3-production. This is doable by adding an IAM policy to each of those roles:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "kms:GenerateRandom"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                "kms:Encrypt"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:kms:us-east-1:12345:key/your-authnz-key-id"
            ],
            "Condition": {
                "StringEquals": {
                    "kms:EncryptionContext:to": "confidant-production",
                    "kms:EncryptionContext:user_type": "service",
                    "kms:EncryptionContext:from": "example-production-iad"
                }
            }
        }
    ]
}

Now if you want to remove this service from the instances, you just remove this IAM policy from the IAM roles.

Unfortunately if you use the same IAM role on different instances, you're a bit stuck. My general approach to IAM roles is to scope them as closely to the service as possible, so that it's possible to add/remove policy in a fine-grained approach, but I know not everyone has things setup this way.

- Ryan

--
You received this message because you are subscribed to the Google Groups "confidant-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to confidant-users+unsubscribe@googlegroups.com.
To post to this group, send email to confidant-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/confidant-users/4ce73103-ddb9-452d-b29e-99c4ca9fd496%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Yann Mahé]

Thanks a lot for the detailed answer Ryan,

In most cases, removing a service access from an IAM role is what I would need and is covered by Confidant 🙌.

When it comes to removing access from a specific instance, having a unique IAM role per instance sounds quite difficult to setup (especially with autoscaling groups). However, isolating the instance at the network level with a relevant security group should work well enough (as long as the instance is part of a VPC to control egress traffic).

Thanks again,

Yann

To unsubscribe from this group and stop receiving emails from it, send an email to confidant-use...@googlegroups.com.
To post to this group, send email to confida...@googlegroups.com.