What affect on our applications will changing the Heroku API Key have? - heroku

Our organization has a number of Rails applications (websites) deployed to Heroku. A former devleoper has left the organization, and as good practice we want to change the Heroku API key associated with our account to prevent any modifications to the apps via the Heroku CLI.
I know that the Heroku API Key is used for Heroku CLI access (it gets cached in ~/.heroku/credentials), but not certain what else it is used for. Specifically, do 3rd-party add-ons in the Heroku platform (e.g. New Relic, Hoptoad/Airbrake, Sendgrid, etc) use this, and therefore require reconfiguring if the API Key is changed? Heroku throws up a fairly generic (and non-informative) error message when you click the "regenerate" button to change it.
Because the term "API Key" is so generic, want to be clear that this is the single API Key associated with each Heroku account accessible via "My Account" link. Image (and warning message) below.

Asked Heroku Support. This is what I got back:
"you can safely change your API key at any time, as we don't give it to any add-on providers. That alert is meant to remind you that if you added your API key to any application or service (ie for auto scaling, manually provision workers, etc) it will stop working until you provide it a new key."
I requested that they update the interface/documentation to make this more clear.

Also remove him from being a collaborator on all your projects so he can't push to them via git.
Out of curiousity (i'd never seen reset key in the admin) I tried it. When I then tried to use the CLI against one of my apps I was asked to reauthenticate - but i can't now get back in - doh! The same username/password works via the site. I'll ping support and report back,
UPDATE:
So it appears my problem is entirely due to the Heroku Accounts (https://github.com/ddollar/heroku-accounts) plugin that I'm using which stores a copy of the key in the ~/.heroku/accounts/ file. Support got me to remove the folder and it all works now - just something to be aware of if you reset your API key.

Related

Can't login account because lost code google authenticator [duplicate]

My mac brokedown.Thus, I can't use the touchID to verify myself anymore on heroku. Thus, the only other option is to use 1-time password generator which I don't even have it setup & you need to login (and verify) to be able to setup. What shall I do? How can I gain access to my heroku account?
Heroku recommends having a back-up in place:
We recommend registering another verification method to ensure that you can log in to Heroku on other devices where a built-in authenticator is not present.
and:
Recovery codes provide an important backup if your usual MFA verification method is not available. For example, if you normally use Salesforce Authenticator but forget your mobile phone one day, you can still log in using a recovery code. Generate a list of ten single-use recovery codes that you can keep in a safe place until you need them.
This is always a good idea when using MFA with any service.
If you do not have another authentication method registered and you don't have recovery codes, you'll have to ask for help. How you do that depends on whether you're a member of an enterprise account:
Registering multiple MFA verification methods is strongly recommended.
If you’re a member of a Heroku Enterprise Account and need help with recovering access when your MFA verification method isn’t available:
Your Enterprise Account admin can generate a temporary verification code that allows you to log in to your account (starting August 2021)
You can contact support for help.
If you're not a member of a Heroku Enterprise Account:
e-mail account-lockout#heroku.com for help.
We may request additional information to recover access to ensure that an attacker is not attempting to access your account.

Debugging permission denied in Cloud Firestore SDK (Golang)

I am experienced in working with AWS but this is my first foray onto Google cloud and I am stuck on how to debug it properly. I am building a simple experimental setup, using Cloud Firestore to store some data and planning to do some small API functions to query it.
I am inputting my information from a Go app, which I built using the official SDK for Go. Everything builds fine, but when I run it I see nothing other than rpc error: code = PermissionDenied desc = Missing or insufficient permissions..
I have tried setting the authentication to open in the Firestore rules console (allow read, write: if true), but I still see the same error, so it seems to be an issue with the credentials I have generated rather than Firestore itself.
The credentials in question were generated in the main Google Cloud Console, under Service Accounts. I've saved it out as a JSON file and am loading this into the app via option.WithCredentialsFile() which is then passed into the NewFirestoreWriter() constructor.
It's far from obvious, to me at least, exactly how to configure the permissions on the Service Account as it seems to work quite differently from Amazon IAM. I was expecting to find a way to add on specific actions related to Firestore but I can't find anything at all like that once the service account is created. Under Permissions, it looks like I can associate other accounts with the service account, which seems to be the other way around to what I want to do. Or do I need to assume another identity once I have the service account in order to do anything, a la Amazon STS? Or am I barking up the wrong tree here?
I am running locally while I am playing with the apps, planning to think about deployment later.
I guess my questions are:
Should I be using a different form of credential when making programmatic writes to Firestore?
What permissions need to be on the credential that I am using?
How do the Google Service Account permissions interact with the Firestore access rules, or are they completely separate?
Thanks in advance for your help.
I finally worked out the answer. Turns out I was reading some of the screens too fast....
The programmatic approach with the credential was fine, but the service account setup was not.
In case anyone else has a similar issue, the fix was to:
Go to "Access" under IAM (NOT identity). Coming from AWS this confused me a little because I was expecting roles to be a sublevel to identity rather than a seperate level
Click the Edit button next to the service account
Add the Cloud Datastore User and Cloud Datastore Owner roles (I'll work on trimming down permissions now it's working!). This confused me particularly because I was looking for "Firestore" or "Cloud Firestore", and there is the very similarly named "Cloud Filestore" which tripped me up.
After a few seconds, it started working.
According to https://cloud.google.com/firestore/docs/reference/libraries?_ga=2.87049368.-1865513281.1592929406#server_client_libraries,
In this environment, requests are not evaluated against your Firestore security rules
So I reset my access permissions in Firebase back to allow read, write: if false.

Is there a Heroku webhook for Heroku Postgres credential rotation?

I'm following the instructions in the Heroku Postgres docs for creating an external application that connects to Heroku Postgres for its data layer. The instructions mention that the credentials are automatically rotated and I must handle this myself.
I read more docs to learn about webhooks existing to help notify the rest of your system that changes have happened in your Heroku services. This made sense to me to be an area where the Heroku devs would have implemented this. There must be a webhook that exists that I could use to be notified when the credential rotation happens. I found that there was the api:addon webhook which had the update event. I tested this webhook, expecting this to be what I was looking for, but I found that it was not fired upon credential rotation. It was only fired when I provisioned or deleted more Heroku Postgres add-ons.
Since the webhook I need doesn't exist, I coded a workaround where I expect a PostgreSQL library auth error to be thrown while my AWS Lambda executes. If an error is thrown, I assume it's from the rotation and I have the still running Lambda function fetch new credentials using the Heroku API and try the PostgreSQL query again, at which point it works unless there are other errors. I tested this while manually rotating my credentials and it worked okay, but it's kind of ugly code. See here for a detailed example.
So at this point, I'm wondering if the webhook I'm looking for does exist and I just wasn't able to find it. Or, if it doesn't exist, I would like to request it as a new feature. I understand that the Heroku team may not want people picking their add-ons a la carte, and they want people to use the entire Heroku platform, but I think it would add a lot of value to the Heroku platform. Personally, I've enjoyed getting into more and more cloud services as I learn since I'm usually able to choose them a la carte. For example, AWS doesn't forbid me from only using S3 and nothing else from them. They do as much as they can to make it easy for me to link my applications to it, no matter what other cloud services I use.
I contacted Heroku directly to ask if this type of webhook existed and I received a useful response from them:
There isn't a webhook specifically for credential rotations, although
with a bit of logic you can sort of recreate the same thing. Whenever
you Postgres credentials rotate, it will trigger a new release, which
does trigger a webhook. You can use that to inspect the release via
the API to determine if the values changed.

Using Parse after Installing Parse Server

If I follow the directions and install the Parse server via Heroku and MongoDB, will I then be able to continue to use Parse commands in my code for current and new apps?
That is, will following these instructions allow me to continue using Parse for in-app purchases, data storage, and push notifications, or will I still have to learn the ins and outs of a different backend service?
Thanks,
Eli
After you set up the Parse Server via Heroku and MongoDB, you will be able to use most of your current code, with some slight modifications. In your client apps, you will have to point to the new server location in the Parse initialization.
As of right now, Parse server does not support in-app purchase verification, as far as I know. Right now it supports:
CRUD operations
Schema validation
Pointers
Users, including Facebook login and anonymous users
Files
Push Notifications
Installations
Sessions
Geopoints
Roles
Class-level Permissions
More information is available at the Official GitHub for Parse-Server including setup instructions and a quick setup button for Heroku

Automated testing of installation process for Google Marketplace app

Is there any easy way to repeatedly test the installation process of a Google Marketplace App on a new domain? It seems as though when you try to install an app to a domain to which it's already been installed, parts of the process are short-circuited, even if the app's permissions on that domain have been revoked. Is there any way around this short of registering a throwaway domain for every test? Being able to automate this test would be even better, but even a repeatable manual test would be very useful.
Unfortunately you need to delete the application and install it again each time from what I gather.
You can revoke the auth here: https://www.google.com/a/your-domain-here/IssuedAuthSubTokens
You definitely don't need to register throwaway domains every time.
If you're trying to test your integration, there is "TEST INSTALL FLOW' button right in the Google APIs Console that starts a test flow. Here's a screenshot:
That's especially useful when you want to test your integration before it is published to the Google Apps Marketplace (but it still works once it is published.)
If you actually install it from the Marketplace as a tester or once published, you can go to the app listing and remove the app. Since we've launched I've added and removed my apps that way quite a few times :) Here's a screenshot:
#aleckz suggestion won't actually work since tokens are Admin authorized and not revokable by the domain user.

Resources