by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Ryan Lane
    @ryan-lane
    one sec. maybe we didn't add docs
    right, so the only thing that causes tags to be available right now is TAGS_EXCLUDING_ROTATION
    Matt
    @mtanatwine
    something else I noticed, the "USERS_FILE" env var is specifically mentioned under the 'Google auth ...' heading, but after delving into the code I could see it's also used with SAML too. May be worth moving that elsewhere, or referencing it on the SAML bit too.
    Ryan Lane
    @ryan-lane
    in the development config:
      MAXIMUM_ROTATION_DAYS=10
      TAGS_EXCLUDING_ROTATION=["ROTATION_EXCLUDED"]
      ROTATION_DAYS_CONFIG={"FINANCIALLY_SENSITIVE": 1}
    ah, yeah, that's probably in the wrong section. I think it should be generic and just match against the auth'd users
    the support we have right now, that sends back server defined tags back to the UI, is to show dates to end-users on when a credential should be rotated
    and you can tag credentials to override the default days
    Matt
    @mtanatwine
    Ahh. OK, I was thinking that we could somehow use the tags as part of the context, i.e. a service in dev would always send that as part of the request, and you could somehow filter by dev credentials / services. Probably a bit outside the scope of what you're using them for.
    Ryan Lane
    @ryan-lane
    yeah, this particular tag support is for modifying behavior
    I think what you want to do is possible, but would need to be a feature on the server and client side
    client side it would be "filter by tag", and server side would be a setting for a set of server defined tags
    Ryan Lane
    @ryan-lane
    lyft/confidant#296 <-- bug for limit issue
    Matt
    @mtanatwine

    Yeah. I was thinking kind of like how it works in Prometheus where you can specify a label and query for it, etc. Like I said, a nice to have, but not a dealbreaker. We're just going to name the services appropriately for each environment, since we're planning to use it across multiple accounts.

    I was putting together some changes to PR eventually once I'm done implementing Confidant. I noticed when you hit the app after being redirected from SAML and you're not on the whitelist, you just get an empty looking app. It looks like it aborts with a 403 in code, but no message pops up, and it also doesn't show the user's e-mail address at the top right.

    Matt
    @mtanatwine
    But yeah, thanks for the assist with the history thing and explaining how the tags work. Looking forward to getting all this working as currently every app has its own set of KMS keys, and 2 IAM policies, each for encrypting and decrypting
    Ryan Lane
    @ryan-lane
    yw!
    yeah, the failed login experience can be better
    in our case, you get rejected at the SAML provider rather than at confidant
    Matt
    @mtanatwine

    Hello... me again. I'm trying to use confidant in a pod to pull some test credentials, and I'm getting the following error:
    botocore.exceptions.ClientError: An error occurred (AccessDenied) when calling the GetUser operation: User: arn:aws:sts::xxxx:assumed-role/k8s-sbxxxx/botocore-session-1594743099 is not authorized to perform: iam:GetUser on resource: user botocore-session-1594743099
    We're not using confidant to manage grants as we plan on using it across multiple accounts and trusting that other account to manage its IAM is acceptable, since we manage that too. I don't recall any documentation that says your service needs permissions to perform iam:GetUser, so I'm just confused as to why I'm getting that error. I went on and allowed iam:GetUser, and I now get:
    botocore.exceptions.ClientError: An error occurred (ValidationError) when calling the GetUser operation: Must specify userName when calling with non-User credentials

    Am I doing something daft?

    Ryan Lane
    @ryan-lane
    hm. let me look at the permissions we're setting
    @mtanatwine that's from the pod trying to fetch from the server, right? not the server?
    on the server side we're not setting getUser from what I can see
    let me look at the client code. it's possible it uses GetUser in some cases
    (but it isn't required)
    ah, yeah, if the auth context is set to user and the "from" context isn't set, it'll use GetUser to try to auto-set the from context
    if you explicitly set the from context, that won't happen
    Matt
    @mtanatwine
    I've got that set in the /etc/confidant/config thusly:
      auth_context:
        from: sb0001-dev
        to: k8s-confidant
        user_type: service
    and yeah, it's from the pod trying to fetch from the confidant server
    Matt
    @mtanatwine
    ok, nevermind.. I had a leftover ~/.confidant that I'm fairly sure I checked for earlier but apparently not :facepalm:
    Ryan Lane
    @ryan-lane
    ah. heh. no worries!
    Matt
    @mtanatwine
    This might be a dumb question, but I couldn't find any reference in the docs or from the command line help output... is there no way of adding regular credentials and services via the client or programmatically? I've found some routes in the code, but it appears to only be supported when using the web interface. I only ask as we have a lot of credentials to add across all our environments and it would be a hell of a lot quicker to write some code to mass import this stuff.
    Ryan Lane
    @ryan-lane
    hm, yeah, it looks like the CLI doesn't directly support it. we have code for creating/updating blind credentials, but not credentials
    the APIs for the CLI and web work the same way, though
    (I'm not really able to add CLI support right now, but it should be straightforward if you were to add support, and we'd love to have the help)
    Matt
    @mtanatwine
    I'm guessing then to authenticate using the cli, you'd need to use kms user authentication, and the only way that confidant verifies that you're authorised to do it is by deferring to IAM, i.e. whether the user is allowed to encrypt with the user key
    Ryan Lane
    @ryan-lane
    yep, exactly
    you can restrict to individual users with IAM for this
    or to groups
    confidant ships with a default ACL setup, but also has ways to customize it with code
    Matt
    @mtanatwine
    yeah, that was a stretch goal of ours but not a requirement to get it implemented
    Ryan Lane
    @ryan-lane
    note that you want the "user" kmsauth type for this. the default ACL limits the "service" kmsauth type to get_service
    Ryan Lane
    @ryan-lane
    yep!
    Matt
    @mtanatwine
    just a heads up, it says here (https://lyft.github.io/confidant/api.html#post--v1-credentials) that enabled defaults to true, but it wouldn't let me post unless I set it in my post body.
        raise ValueError("Attribute '{0}' cannot be None".format(attr.attr_name))
    ValueError: Attribute 'enabled' cannot be None
    Matt
    @mtanatwine
    I'd submit a PR to contribute / fix but my main prio is getting this system implemented here first 😁... maybe afterwards I can look into it
    Ryan Lane
    @ryan-lane
    @mtanatwine if you find things like that, please open some bugs. I have time to fix that kind of stuff for sure :)
    (I hate bad docs)
    Matt
    @mtanatwine
    I'm fairly sure you'll regret asking me to do that. I've seen quite a few bits that could do with some love :joy:
    Ryan Lane
    @ryan-lane
    hahaha, nah, I like writing docs and it's good to have a fresh set of eyes point out issues