3 ms·

Okay but now how do you recommend I hook up my Sentry instance to create tickets in Jira, now that Jira has deprecated long-lived keys and I have to refresh my

Okay but now how do you recommend I hook up my Sentry instance to create tickets in Jira, now that Jira has deprecated long-lived keys and I have to refresh my token every 6 weeks or whatever. It needs long-lived access. Whether that comes in the form of a OAuth refresh token or a key is not particularly interesting or important, IMO.

tptacek 6mo ago
You do what you can. Eliminating long-lived keys isn't always possible; you set up rotation instead.
- datadrivenangel 6mo ago
  Does having to refresh the key every 6 weeks instead of every year or whatever actually make a meaningful difference security-wise?
  - 1024kb 6mo ago
    If the key becomes compromised, rotating the key sooner means you potentially limit the damage from unauthorised access.
  - tptacek 6mo ago
    Yes? That's a huge difference.
  - plorkyeran 6mo ago
    At the minimum you’ll remember how to do it if you have to do it every six weeks.
- nightpool 6mo ago
  I disagree, I think increasing manual toil (having to log into Sentry every 6 months to put in a new Jira token) increases fatigue substantially for, in this case, next-to-no security benefit (Sentry never actually has any less access to Jira than it does in the long-lived token case, and any attacker who happens to compromise them is going to be gone well before six months is up anyway). Instead, the right approach in this case is to worry less about the length of the token and more about making sure the token is properly scoped. If Sentry is only used for creating issues, then it should have write-only access, maybe with optional limited access to the tickets it creates to fetch status updates. That would make it significantly less valuable to attackers, without increasing manual toil at all, but I don't know any SaaS provider (except fly, of course) that supports such fine-grained tokens as this. Moving from a 10 year token to a 6 month token doesn't really move the needle for most services.
  - akerl_ 6mo ago
    This sounds more like a reason to automate token management than an argument for long lived tokens.
    - ferngodfather 6mo ago
      But then you just move the security issue elsewhere with more to secure. Now we have to think about securing the automation system, too. This is the same argument I routinely have with client id/secret and username/password for SMTP. We're not really solving any major problem here, we're just pretending it's more secure because we're calling it a secret instead of a password.
      - Flimm 6mo ago
        Secrets tend to be randomly-generated tokens, chosen by the server, whereas passwords tend to be chosen by humans, easier to guess, and reused across different services and vendors.
        collabs 6mo ago
        How does this apply to ssh public keys?
        akerl_ 6mo ago
        > Long-lived production SSH keys may be copied around, hardcoded into configuration files, and potentially forgotten about until there is an incident. If you replace long-lived SSH keys with a pattern like EC2 instance connect, SSH keys become temporary credentials that require a recent authentication and authorization check.
      - orf 6mo ago
        It’s like 12 lines of terraform to fully automate this, inside your existing IaC infrastructure. It’s not complex.
deleted 6mo ago
[deleted]
420official 6mo ago
OIDC with JWT doesnt need any long lived tokens. For example, I can safely grant gitlab the ability to push a container to ECR just using a short-lived token that gitlab itself issues. So the answer might be to ask your sentry/jira support rep to fast track supporting OIDC JWTs. - https://docs.gitlab.com/ci/secrets/id_token_authentication/#configure-id-tokens-in-a-cicd-job https://docs.gitlab.com/ci/secrets/id_token_authentication/#... - https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...

tptacek 6mo ago

You do what you can. Eliminating long-lived keys isn't always possible; you set up rotation instead.

datadrivenangel 6mo ago
Does having to refresh the key every 6 weeks instead of every year or whatever actually make a meaningful difference security-wise?
- 1024kb 6mo ago
  If the key becomes compromised, rotating the key sooner means you potentially limit the damage from unauthorised access.
- tptacek 6mo ago
  Yes? That's a huge difference.
- plorkyeran 6mo ago
  At the minimum you’ll remember how to do it if you have to do it every six weeks.
nightpool 6mo ago
I disagree, I think increasing manual toil (having to log into Sentry every 6 months to put in a new Jira token) increases fatigue substantially for, in this case, next-to-no security benefit (Sentry never actually has any less access to Jira than it does in the long-lived token case, and any attacker who happens to compromise them is going to be gone well before six months is up anyway). Instead, the right approach in this case is to worry less about the length of the token and more about making sure the token is properly scoped. If Sentry is only used for creating issues, then it should have write-only access, maybe with optional limited access to the tickets it creates to fetch status updates. That would make it significantly less valuable to attackers, without increasing manual toil at all, but I don't know any SaaS provider (except fly, of course) that supports such fine-grained tokens as this. Moving from a 10 year token to a 6 month token doesn't really move the needle for most services.
- akerl_ 6mo ago
  This sounds more like a reason to automate token management than an argument for long lived tokens.
  - ferngodfather 6mo ago
    But then you just move the security issue elsewhere with more to secure. Now we have to think about securing the automation system, too. This is the same argument I routinely have with client id/secret and username/password for SMTP. We're not really solving any major problem here, we're just pretending it's more secure because we're calling it a secret instead of a password.
    - Flimm 6mo ago
      Secrets tend to be randomly-generated tokens, chosen by the server, whereas passwords tend to be chosen by humans, easier to guess, and reused across different services and vendors.
      - collabs 6mo ago
        How does this apply to ssh public keys?
        akerl_ 6mo ago
        > Long-lived production SSH keys may be copied around, hardcoded into configuration files, and potentially forgotten about until there is an incident. If you replace long-lived SSH keys with a pattern like EC2 instance connect, SSH keys become temporary credentials that require a recent authentication and authorization check.
    - orf 6mo ago
      It’s like 12 lines of terraform to fully automate this, inside your existing IaC infrastructure. It’s not complex.

deleted 6mo ago

[deleted]

420official 6mo ago

OIDC with JWT doesnt need any long lived tokens. For example, I can safely grant gitlab the ability to push a container to ECR just using a short-lived token that gitlab itself issues. So the answer might be to ask your sentry/jira support rep to fast track supporting OIDC JWTs. - https://docs.gitlab.com/ci/secrets/id_token_authentication/#configure-id-tokens-in-a-cicd-job https://docs.gitlab.com/ci/secrets/id_token_authentication/#... - https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...